Ichthyostega
0178e11e65
The old implementation relied on two layered APIs: one for the client and one for the implementer of the Allocation state. This is logically sound, yet clumsy in terms of design, since the internal API turns out to be void of actual meaning. It seems possible to eliminate this confusing structure by a clear separation of ''implementation realms'' * the ''mechanics'' of connection state management * the actual implementation of the connection The first can be provided as generic template subclass, while the latter should be confined entirely into the implementation of the `Connection` interface. Doing so requires to keep each part of the implementation strictly focused onto its purpose — something I obviously was not able to see at the time when writing this old implementation, notably because I was completely guided and driven by the test/dummy implementation without considering how an actual implementation of low-level data output would work. |
||
|---|---|---|
| .. | ||
| draw | ||
| DIR_INFO | ||
| dump | ||
| empty.html | ||
| InterfaceConcept_Varga.mm | ||
| renderengine.html | ||
| thinkPad.ichthyo.mm | ||
| uml | ||
| workflow.mm | ||
| Workflow_Verwijlen.mm | ||