🚀 go-pugleaf

Agaricus <Agaricuswebmail@yahoo.com> wrote:
> Nu is mijn vraag heel algemeen hoe begin je aan zoiets want "in het
> wilde weg" code schrijven zal hier zeker tot een slecht resultaat
> leiden.

Toch niet. 'In het wilde weg beginnen' is niet zo slecht als het lijkt.
Meestal geraak je op je eerste ruwe idee al redelijk ver. Na een tijdje
krijg je dan onherroepelijk het idee dat het werkelijk een warboel
is geworden. Je begint steeds meer te denken : als ik van in het begin
dat en dat had gekozen, dan zou het nu veel vlotter gaan. Wel :
dan gooi je gewoon alles (of een heel groot stuk) weg en begin je
opnieuw. Het lijkt inefficient maar is in werkelijkheid verschrikkelijk
effectief. Effectiever in ieder geval dan te proberen vanaf het
eerste moment over te designen.

Toch zijn er een aantal basistips bruikbaar, meer bepaald voor C++.
(Ik gebruik als voorbeeld het probleem van het maken van een
rekenmachine met oneindige precisie, die functies en variabelen
aankan)

1. Een klasse moet 1 wel gedefinieerd concept voorstellen uit je
probleem. Goed : RationaalGetal; Slecht : FunctieOfVariabele.

2. Probeer een klassedefinitie zo klein mogelijk te houden, maar
niet kleiner. Bijvoorbeeld : ipv RationaalGetal::NaarScherm() en
RationaalGetal::NaarString() te voorzien kan je misschien beter
de eerste laten vallen. Indien je later bijvoorbeeld je programma
van een grafische mode ipv textmode wil voorzien hoef je niet
alle NaarScherm te veranderen maar enkel de routine die strings
op het scherm zet.

3. Vergeet const niet. 

4. Altijd proberen klasses te hergebruiken uit je library. Verlies geen
tijd met zelf een string te willen programmeren, of een lijst of een
array. Gebruik gerust std::string, std::list of std::vector. Je leert
relatief weinig door die dingen zelf te willen schrijven. 

5. Indien je klasse geheugen alloceert
		a. alloceren in constructor, dealloceren in destructor
		b. altijd copy constructor voorzien
		c. indien je wil vergelijken, meer dan waarschijnlijk
		operator==(...) zelf schrijven
		d. altijd assignment operator zelf schrijven.
		(trouwens, een assignment operator test eerst of je niet
		aan jezelf aan het assignen bent.)

(enkel indien je virtual al gezien hebt)
6. Indien je een klasse van een virtuele member wil voorzien :
		a. altijd virtuele destructor
		b. in iets grotere projecten, (bijna) altijd virtuele 
		abstracte baseclass

7. protected: members zijn bijna altijd een teken van luiheid. Ofwel zijn
ze werkelijk voor iedereen vrij te veranderen, en dan kan je ze evengoed
public maken. Ofwel moeten er toch bepaalde constraints aan opgelegd
worden, en dan moet je ze private maken. Indien je twijfelt of iets
public, protected of private zou moeten zijn, maak het private.

cu bart

-- 
http://www.irule.be/bvh/