🚀 go-pugleaf

Sjoerd Schreuder wrote:

> Jo Vermeulen wrote:
>> 
>> Sjoerd Schreuder wrote:
>> > Overigens is het slordig om m_pDna, m_pC, m_pJ en m_pV niet te
>> > initialiseren in de constructor.
>> 
>> Die initialiseer ik in de derived classes van interface, maar je hebt
>> gelijk, dat kan ik evengoed hier doen.
> 
> Des te minder je overlaat aan derived classes, des te minder er fout kan
> gaan. Verder voorkom je je daarmee dat dezelfde code op diverse plaatsen
> komt te staan.

Daar geef ik je gelijk in, ik ga het ook veranderen.
 
> Mijn richtlijn is om afgeleide klassen zo min mogelijk vertrouwen.
> Eigenlijk vertrouw ik geen enkele code buiten de huidige klasse.
> Dan spoor je bugs veel sneller op omdat de hoeveelheid code die b.v. bij
> m_pDna kan veel beperkter is. I.p.v. een protected m_useStandardInput zou
> ik dan ook een function "bool UseStandardInput() { return
> m_useStandardInput; }" maken en m_useStandardInput private maken. Dan weet
> je zeker dat niemand die waarde kan veranderen buiten jou om.

Is dit niet wat overdreven? Onze Interface klassen zijn niet geschreven om
ook in andere projecten te gebruiken, dus dan denk ik dat dat een beetje
overkill is. Of ben ik mis?

>> > Ook het gebruik van "using namespace std;" in een header is niet zo
>> > handig.
>>
>> Ik gebruikte eerst std::cout en std::vector enz., maar Visual
>> Studio versie 6 kan daar niet mee overweg. Daarom dat we dus
>> genoodzaakt waren om using namespace std; te gebruiken.
> 
> Vreemd. Ik gebruik ook Visual Studio 6.0 en ik heb nog nooit
> last gehad met std::cout en std::vector. Ik heb wel een recente service
> pack geinstalleerd; misschien ligt het daaraan?

Ik heb SP5 geloof ik. Zolang je vrij basic dingen doet is het OK heb ik
gemerkt, maar wanneer je templates gebruikt gaat het mis (ondersteuning van
VC++ voor templates is vrij slecht). Wij deden dit bijvoorbeeld:

using std::vector;

vector<EenClass>::iterator it;

Dit werkte niet. Ook niet met std::vector. Daarom zijn we overgeschakeld
naar "using namespace std;". Het kan zijn dat ik me vergis met de service
pack, ik heb het op school geprobeerd (misschien dat ze daar niet de
nieuwste SP geinstalleerd hadden), maar met de versie die ze daar hebben
werkt het in ieder geval niet.

>> > Verder lijkt het erop dat een File en een Dictionary steeds met
>> > elkaar verband houden. Waarom heb je geen aparte klasse voor die
>> > combinatie?
>> 
>> Hoe bedoel je? We lezen de dictionary's idd in van een file ja (wordt
>> meegegeven aan de constructor).
> 
> Ik bedoel dit:
>  string m_cFile;
>  string m_jFile;
>  string m_vFile;
>  Dictionary *m_pC;
>  Dictionary *m_pJ;
>  Dictionary *m_pV;
> 
> Het lijkt er erg op dat m_cFile en m_pC bij elkaar horen,
> netzoals m_jFile en m_pJ en m_vFile en m_pV.

Idd :) 

> Ik zou het omzetten in:
>  string_and_Dictionary m_C;
>  string_and_Dictionary m_J;
>  string_and_Dictionary m_V;
> alhoewel ik een betere naam dan "string_and_Dictionary" zou zoeken.

De reden waarom ik die filenames bijhield, was omdat ik dacht dat ik
misschien ooit die Dictionary eens opnieuw moest inlezen, het is wel
redelijk dom ja, die members heb ik helemaal niet nodig. Dus het zal dit
worden:

Dictionary *m_pC;
Dictionary *m_pJ;
Dictionary *m_pV;

cFile, jFile en vFile zijn dan gewoon parameters van de constructor.

> Nog een opmerking: waarom die "useStandardInput" variabele?
> En daarnaast heb je ook een m_inputFile; mij lijkt het dat
> altijd slechts een van de twee wordt gebruikt. Geef gewoon een stream mee,
> dan kun je bij de aanroep beslissen of je std::cin of std::fstream
> gebruikt.

Ja heb je gelijk in, de gebruiker zou eigenlijk moeten kunnen kiezen of hij
de input uit een file leest, of via stdin. Zou handig zijn als ik het in
��n keer kan doen, bedankt!

> Verder zou ik de klasse splitsen. Een interface klasse met alleen
> de puur virtuele functies, en een afgeleide klasse die alle
> protected spul bevat. De interface naar buiten en de interface naar
> de afgeleide klassen zijn daarmee netter gescheiden. En misschien wil
> jij (of iemand anders) ooit wel een afgeleide klasse maken die wel de
> interface implementeerd, maar niets heeft aan al dat protected spul.

De bedoeling was eigenlijk een GUI en console UI te maken. We zouden dus een
ConsoleInterface en GraphicalInterface klasse afleiden van de Interface
klasse. Maar jij denkt dat het beter is die twee klassen af te leiden van
een afgeleide klasse van de (pure) abstracte klasse die al het "protected"
spul bevat, als ik het goed heb?

> Eigenlijk komt het erop neer dat een klasse slechts een ding moet doen.
> Doordat je je op een ding concentreert, kun je dat ene ding veel beter
> doen. Deze klasse doet een tiental dingen. Bovenstaande opmerkingen zijn
> allemaal suggesties om een deel van die functionaliteit in een aparte
> klasse onder te brengen. Het lijkt in eerste instantie overkill, maar je
> code wordt er in het algemeen netter en beter begrijpbaar van. Mits je de
> juiste opsplitsing kiest, en daar komt wat ervaring bij kijken. Maar dat
> is dan ook een van de kenmerken van een goede OO programmeur: de juiste
> opsplitsing in klassen kiezen.

Bedankt voor je suggesties! Onze kennis als "beginnende" OO-programmeurs
wordt wel vrij zwaar getest tijdens dit project, vermits we dit programma
perfect imperatief hadden kunnen maken i.p.v. objectgeorienteerd, het is
dan moeilijk een goede OO structuur te vinden. Moest je nog tips of
opmerkingen hebben, laat maar weten :)

Mvg,

-- 
Jo Vermeulen
Student Computer Science at the tUL
email: jo@lumumba.luc.ac.be
www: http://lumumba.luc.ac.be/jo