boek over hoe een programma opbouwen

Gestart door Havoc, 01 maart 2017, 12:50:22 PM

Havoc

Citaat van: Werner op 27 maart 2017, 00:20:23 AM
Heb eens gezocht in m'n boekenkast, het meeste is taal specifiek, vooral dan Java en C++.

Deze 2 zijn algemeen:
- McConnell, S., Code Complete, Redmond, Microsoft Press, 1993, ISBN 1-55615-484-4
- Gamma, E., et al, Design Patterns; Elements of Reusable Object-Oriented Software, 20ste druk, Upper Saddle River, Addison-Wesley, 2000, ISBN 0-201-63361-2
Je leert er niet mee programmeren, maar er worden wel voorbeelden gegeven van hoe structuur in te brengen, en patronen te herkennen.

En ook, hoewel off-topic, zijn de volgende 2 wel in het Nederlands, en heel goed voor de beginner, dus vermeld ik ze maar:
- Warmer, J., Kleppe, A., Praktisch UML, s.l. Addison-Wesley, 1999, ISBN 90-6789-937-2
- van der Lans, R. F., het SQL leerboek; vijfde herziene uitgave, 5de druk, 3de oplage, Schoonhoven, Academic Service, 2000, ISBN 90-395-0755-4

"Code complete" had ik ondertussen gevonden, maar wanneer ik de tijd ga vinden om die turf te doorworstelen is een ander paar mouwen. De andere referenties ga ik eens opzoeken.

CiteerEn het helpt ook om eens op Wikipedia te zoeken/lezen: bijvoorbeeld https://nl.wikipedia.org/wiki/Model-view-controller-model
Waarbij de controller ook input ontvangt van de spoorbaan (bvb bezetmeldingen), en de view output naar de spoorbaan is (bvb seinen).  Het model is je eigen data structuur, die de secties in je baan beschrijft/opsomt.  De bezetmelders (input) laten je weten in welke sectie er iets gebeurt, en daar kan je de dan de gerelateerde seinen mee aansturen (output).  De "fysieke" in- en output kan je loskoppelen met een aparte reeks functies (bibliotheek) van je eigenlijke programma code.
Dat is wat ik begrepen uit je bovenstaande vragen, maar ik kan me vergissen.

Je zit er heel dicht bij. Het opzet was (is?) om te werken zoals een state machine: input lezen, verwerken, nieuwe output genereren. Enig verschil is dat er geen definitie vooraf van die states gaat zijn, enkel een soort "rule book".

De low-level IO loskoppelen van de rest was ik al van plan. Vooral omdat ik de software zoveel mogelijk onafhankelijk van de hardware wil maken. Dus het programma stuurt gewoon door hoe het de IO's wil (lijst adressen en bits/bytes) en de lib lost het op. Als het dan een hardware doosje van merk X of Y wordt of verschillende dozen, enkel de lib moet herwerkt worden. Met dat stuk ben ik al wat begonnen omdat de hardware getest moet kunnen worden dus dat komt al van in het begin van pas. Verder zit ik al aan versie 7 of zo van hoe de data te organiseren. Maar telkens als je dat een weekje laat liggen dan zie je er zo de gaten in. Probleem is dat elke versie tot nu toe meer gaten heeft dan een gruyère.
Met vakantie voor onbepaalde duur.