[C++] MVC in C++ / [Alg] interfaces *

[Verwijderd]

Ik heb in een ver verleden eens in Java geprogrammeerd. In die tijd moest ik mijzelf het MVC model aanleren, op zich werkte dat allemaal prima en overzichtelijk.

Nu heb ik zojuist een opdracht gekregen om een simulatie van een kookproces te maken. Het is een behoorlijke opdracht en dus een behoorlijke hoeveelheid code. Tegenwoordig programmeer ik in C++. Toen ik deze opdracht kreeg moest ik geljik weer aan het MVC model denken omdat je hiermee op verschillende manieren tegen een model aan kunt kijken.... maar mijn vraag is of dit een beetje te implementeren valt in C++. Als ik mij namelijk niet vergis moest ik in Java Listeners ed. gebruiken, maar kan ik deze ook in C++ toepassen?

Ik zou graag ervaringen willen uitwisselen

[Alarmnummer]

ALs je nog een beetje redelijk thuis bent in MVC dan zou je moeten weten dat het zonder probleem kan. En dat MVC een design pattern is die je onder iedere oo taal goed kan toepassen omdat het niet gebonden is aan java.

Het enigste probleem dat je waarschijnlijk tegen zult komen is dat er maar weinig widgets sets zijn zoals Swing die van nature al werken met het MVC principe.

ps: eigelijk zijn de Swing modellen niet te vergelijken met domein modellen, en daarom noem ik ze zelf view-modellen. De enigste taak van een view-model is als dataopslag te werken voor de view (die zelf geen data mag bevatten).

[ Voor 47% gewijzigd door Alarmnummer op 04-09-2003 13:03 ]

[whoami]

Zoals Alarmnummer al zegt:
OO patterns zijn niet gebonden aan een bepaalde taal. Een OO pattern is in eender welke OO taal te gebruiken.

[Woy]

Listeners zijn natuurlijk in C++ redelijk eenvoudig te maken. Een listener is niks meer als een interface. Je moet dan nog een caller hebben die niet veel meer doet als een lijstje met listeners bijhouden en die aan de hand van de interface allemaal aanroepen op het moment dat er een event plaats vindt.

[Alarmnummer]

rwb schreef op 04 september 2003 @ 17:11:
Listeners zijn natuurlijk in C++ redelijk eenvoudig te maken. Een listener is niks meer als een interface.

Ik wist niet dat c++ ook interfaces had

[MSalters]

Ja hoor. C++ heeft een volledige impelemtatie van Multiple Inheritance (interface&implementatie)

[Alarmnummer]

MSalters schreef op 04 september 2003 @ 17:40:
Ja hoor. C++ heeft een volledige impelemtatie van Multiple Inheritance (interface&implementatie)

Voor zover ik weet is er bij C++ niet sprake van een interface zoals dat bij java/delphi en c# het geval is. Daar kan een interface per definitie, alleen een specificatie zijn van een stuk functionaliteit en nooit een implementatie. Bij c++ valt dit niet aan te geven dat je altijd en alleen maar abstracte/virtuele methodes voor een 'interface' kan hebben.

[ Voor 4% gewijzigd door Alarmnummer op 04-09-2003 17:44 ]

[Woy]

Alarmnummer schreef op 04 September 2003 @ 17:42:
[...]

Voor zover ik weet is er bij C++ niet sprake van een interface zoals dat bij java/delphi en c# het geval is. Daar kan een interface per definitie, alleen een specificatie zijn van een stuk functionaliteit en nooit een implementatie. Bij c++ valt dit niet aan te geven dat je altijd en alleen maar abstracte/virtuele methodes voor een 'interface' kan hebben.

Het is inderdaad niet een interface zoals bij java. Maar je kan natuurlijk een class maken met alleen abstracte methods dan heb je precies hetzelfde bereikt als een interface. Het enige verschil is dus dat het in java/delphi/c# al afgedwongen wordt door de compiler als je het keyword interface gebruikt.

[Alarmnummer]

Genoeg over het interface gebeuren

[ontopic]
In Pattern-Oriented Software Architecture, Volume 1: A System of Patterns wordt mvc ook behandeld met oa c++ voorbeelden.

[.oisyn]

Alarmnummer schreef op 04 September 2003 @ 17:42:
[...]

Voor zover ik weet is er bij C++ niet sprake van een interface zoals dat bij java/delphi en c# het geval is. Daar kan een interface per definitie, alleen een specificatie zijn van een stuk functionaliteit en nooit een implementatie. Bij c++ valt dit niet aan te geven dat je altijd en alleen maar abstracte/virtuele methodes voor een 'interface' kan hebben.

En wat is het verschil tussen een interface, en een klasse met alleen maar abstracte methodes en geen attributen? Een keyword "interface" introduceren voor iets dat al kan is vrij onzinnig, het zit alleen in Java omdat die verder geen multiple inheritance ondersteund. Ik zou het dus meer een workaround voor Java noemen, dan dat het een gemis van C++ is

[whoami]

.oisyn schreef op 04 September 2003 @ 19:29:
[...]


En wat is het verschil tussen een interface, en een klasse met alleen maar abstracte methodes en geen attributen?

In een interface kan je gewoon geen attributen definieren. In een abstract class heb je die mogelijkheid wel.

[.oisyn]

Ik vraag wat het verschil is tussen een interface en een klasse met alleen abstracte methodes en geen attributen. Die is er niet

En waarom zou je eigenlijk geen attributen mogen definieren in een interface? Dat is gewoon een restrictie die Java oplegt (om implementatie-redenen). Want waarom zou een interface geen attributen mogen hebben?

[Glimi]

.oisyn schreef op 04 september 2003 @ 19:35:
Ik vraag wat het verschil is tussen een interface en een klasse met alleen abstracte methodes en geen attributen. Die is er niet

Oh, jawel. Interfaces mogen namelijk wel static variabelen hebben [/wijsneus]

En waarom zou je eigenlijk geen attributen mogen definieren in een interface? Dat is gewoon een restrictie die Java oplegt (om implementatie-redenen). Want waarom zou een interface geen attributen mogen hebben?

Omdat echte members zoals jij bedoeld geïnstantieerd moeten worden bij creatie van het object. Dit impliceert dat interfaces gecreëerd moeten worden en een apart object moeten hebben om z'n lokale variabelen in op te slaan. Dit zou dan weer inhouden dat je twee gevallen zou hebben
• Een interface instantie (sowieso raar) waarvoor de variabelen gedeeld zijn
• Verschillende instanties.

Noujah, hopelijk begrijp je het een beetje wat ik hier vaag lul

[.oisyn]

Glimi schreef op 04 September 2003 @ 20:53:
Oh, jawel. Interfaces mogen namelijk wel static variabelen hebben [/wijsneus]

je lijkt whoami wel
het gaat er niet om wat wel mag of wat niet mag, ik vroeg wat het verschil was tussen een klasse met alleen abstracte methoden en een interface

Omdat echte members zoals jij bedoeld geïnstantieerd moeten worden bij creatie van het object. Dit impliceert dat interfaces gecreëerd moeten worden en een apart object moeten hebben om z'n lokale variabelen in op te slaan. Dit zou dan weer inhouden dat je twee gevallen zou hebben
• Een interface instantie (sowieso raar) waarvoor de variabelen gedeeld zijn
• Verschillende instanties.

Noujah, hopelijk begrijp je het een beetje wat ik hier vaag lul

onzin, dat is een implementatie-detail. Net als dat een interface methoden kan hebben, kan een interface ook variabelen hebben. Waar die staan is onbelangrijk, net als bij de methoden. Op implementatie-niveau staat de plek van de methode beschreven ergens in de interface (in de vtable). Daar zou net zo goed kunnen staan waar de variabelen staan. De variabelen worden dan niet geinstantieert met de interface, maar de compiler kan er wel bij

[Glimi]

.oisyn schreef op 04 September 2003 @ 21:05:
je lijkt whoami wel
het gaat er niet om wat wel mag of wat niet mag, ik vroeg wat het verschil was tussen een klasse met alleen abstracte methoden en een interface

Ja, en daarmee wou je lekker impliceren dat het precies hetzelfde was. Ik ken je langer dan vandaag, nare .oisyn

onzin, dat is een implementatie-detail. Net als dat een interface methoden kan hebben, kan een interface ook variabelen hebben. Waar die staan is onbelangrijk, net als bij de methoden. Op implementatie-niveau staat de plek van de methode beschreven ergens in de interface (in de vtable). Daar zou net zo goed kunnen staan waar de variabelen staan. De variabelen worden dan niet geinstantieert met de interface, maar de compiler kan er wel bij

Zoals jij het zo beschrijft (+ wat discussie op ICQ) kan het inderdaad, echter dan zal er wel verschil ontstaan in implementatie van objecten die een interface implementeren met members of objecten die dat niet doen

Verder blijft natuurlijk de vraag hoe veel voordeel dat dan met zich mee kan brengen. Ik had je het volgende voorbeeld al laten zien:

Java:

public interface TheInterfaceExample {
  
  String name;
  public String getName();
}

Wat dan als getName ipv return name; een return firstName + " " + lastName; moet gaan doen? Dan heb je een variabele voor niets ergens hangen.
Dit is ook weer op te lossen met een property zoals je zei, maar ga je dan als interfacebouwer niet te veel definieren? Interfaces zijn immers bedoeld voor 'losse koppeling' van Objecten. Maar daar waren we het ook al voornamelijk over eens

_{Raar eigenlijk een gesprek samenvatten in een post Maarja misschien hebben anderen er nog meningen over}

[whoami]

.oisyn schreef op 04 September 2003 @ 19:35:
Ik vraag wat het verschil is tussen een interface en een klasse met alleen abstracte methodes en geen attributen. Die is er niet

Ik bedoel dat bij een Interface de compiler dat afdwingt, en bij een abstract class niet.

[.oisyn]

Glimi schreef op 04 September 2003 @ 22:01:
Ja, en daarmee wou je lekker impliceren dat het precies hetzelfde was. Ik ken je langer dan vandaag, nare .oisyn

zeg dat dan gewoon, en ga niet een dom antwoord zoeken op een retorische vraag

Zoals jij het zo beschrijft (+ wat discussie op ICQ) kan het inderdaad, echter dan zal er wel verschil ontstaan in implementatie van objecten die een interface implementeren met members of objecten die dat niet doen

nou ja dat hoeft natuurlijk niet, maar voor een werkelijke loskoppeling van object en interface is dat idd nodig. Maar die loskoppeling hoeft natuurlijk ook niet per se

Dit is ook weer op te lossen met een property zoals je zei, maar ga je dan als interfacebouwer niet te veel definieren? Interfaces zijn immers bedoeld voor 'losse koppeling' van Objecten. Maar daar waren we het ook al voornamelijk over eens

En je kan natuurlijk ook gewoon naam zetten als voornaam + " " + achternaam, en die wijzigen zodra voornaam of achternaam wijzigt. Dat lijkt in dit geval misschien overbodig, maar ik kan me soortgelijke situaties voorstellen waarbij het juist efficienter is (als naam bijvoorbeeld enorm vaak opgevraagd gaat worden)

whoami schreef op 04 September 2003 @ 22:03:
[...]

Ik bedoel dat bij een Interface de compiler dat afdwingt, en bij een abstract class niet.

Zie boven, de reden dat de compiler het afdwingt is omdat java geen multiple inheritance ondersteund, en dus ook geen attributen kan 'onthouden' bij een interface. Maar dat betekent natuurlijk nog niet dat een "interface" (interface in het algemeen, niet Java's interface) geen attributen zou mogen hebben

[whoami]

Waarom zou een interface wel attributen moeten hebben?
Een interface geeft gewoon aan welke functionaliteit een class moet ondersteunen, daar heb je helemaal geen data-members voor nodig.

[.oisyn]

data-members vallen ook onder functionaliteit. En ik zeg niet moeten, ik zeg alleen dat het zou kunnen.

[whoami]

.oisyn schreef op 04 September 2003 @ 22:21:
data-members vallen ook onder functionaliteit.

Ja, maar dat is dan al implementatie-specifiek, terwijl een interface gewoon beschrijft welke functionaliteit er moet zijn.
De implementatie van die functionaliteit wordt gedaan in de class die deze interface implementeert.
Daarom zie ik gewoon het nut niet in van een member in een interface.

[.oisyn]

en waarom zou een interface niet kunnen definieren dat die class een bepaalde datamember moet hebben?

[whoami]

.oisyn schreef op 04 September 2003 @ 22:25:
en waarom zou een interface niet kunnen definieren dat die class een bepaalde datamember moet hebben?

Je kan wel (in .NET dan) in een interface definieren dat een bepaalde class een bepaalde property moet hebben.
Is dat ook al goed?

[.oisyn]

nou, daar heb je het al. Waarom is het dan niet goed dat interfaces datamembers mogen hebben?

[whoami]

.oisyn schreef op 04 September 2003 @ 22:31:
nou, daar heb je het al. Waarom is het dan niet goed dat interfaces datamembers mogen hebben?

Omdat een property eigenlijk niet meer of minde is dan een getter/setter functie.
Je zegt gewoon dat een class een property moet hebben met een bepaalde naam, maar wat de implementatie van die property moet zijn, laat je over aand ie class.

[MSalters]

Tenslotte is een member gewoon een combinatiegetter/setter

[Glimi]

Maar toch vind ik het zelf niet echt een nuttig idee om een member al met type en al te declareren in een interface. Bijvoorbeeld:

Java:

public interface Example {

  String _value;
  public String getValue();
  public void setValue( String value );
}

public class ExampleImpl extends Example {

  // Need to do a lot of addition's in loops, so I better use a 
  // stringbuffer
  Stringbuffer _value = new Stringbuffer( );

  public void setValue( String value ) {

    _value.set( value );
  }

  public String getValue( ) {

    return _value.toString();
  }
}

Je ontneemt hier de vrijheid van de programmeur om te kiezen voor een StringBuffer omdat je al een type vastlegt. Natuurlijk is dat een slechte stijl om dit te doen, maar weet je precies wat en hoe de implementator van de klasse dat wil doen. Wil je het wel weten?

Mede omdat members toch zouden worden gebruikt om implementatiedata te bevatten is denk ik in Java mede-gekozen om dit niet te ondersteunen.

[.oisyn]

MSalters schreef op 04 September 2003 @ 22:34:
Tenslotte is een member gewoon een combinatiegetter/setter

idd
uit mijn ICQ conversatie met Glimi:

.oisyn: getters en setters zijn natuurlijk ook precies hetzelfde als attributen

[...]

.oisyn: een variabele uitlezen is dan ook niet meer dan tegen de interface zeggen: "heej, ik wil weten wat je naam is". Of dat nou via een variabele of via een methode gaat maakt niets uit

[Alarmnummer]

Ik zie dat het toch een heel interface verhaal is geworden

Zoals ik al hierboven heb beschreven is het voordeel aan een interface dat je compiletime kan afdwingen dat een interface alleen een beschrijving is, en geen implementatie. Bij een class kan je dit onmogelijk voor elkaar krijgen. En idd, het verschil tussen een puur abstracte class en een interface is klein, maar waarom zie ik dan zoveel c++ code waarin ze een interface maken en ook meteen maar wat implementatie in plaatsen?

Door het kleinste beetje implementatie toe te voegen (die misschien wel erg voor de hand ligt), maak je het een stuk lastiger om allerlei design patterns te gebruiken zoals bv de decorator, proxy omdat je geen puur abstracte classes tot je beschikking hebt,

[ Voor 22% gewijzigd door Alarmnummer op 05-09-2003 10:56 ]

[Woy]

Alarmnummer schreef op 05 September 2003 @ 10:43:
Ik zie dat het toch een heel interface verhaal is geworden

Zoals ik al hierboven heb beschreven is het voordeel aan een interface dat je compiletime kan afdwingen dat een interface alleen een beschrijving is, en geen implementatie. Bij een class kan je dit onmogelijk voor elkaar krijgen. En idd, het verschil tussen een puur abstracte class en een interface is klein, maar waarom zie ik dan zoveel c++ code waarin ze een interface maken en ook meteen maar wat implementatie in plaatsen?

Door het kleinste beetje implementatie toe te voegen (die misschien wel erg voor de hand ligt), maak je het een stuk lastiger om allerlei design patterns te gebruiken zoals bv de decorator, proxy omdat je geen puur abstracte classes tot je beschikking hebt,

Ja maar dat is dan de fout van de programmeur. In java zou iemand er ook voor kunnen kiezen om een abstract class te maken in plaats van een Interface.

[Alarmnummer]

rwb schreef op 05 September 2003 @ 11:55:
[...]
Ja maar dat is dan de fout van de programmeur. In java zou iemand er ook voor kunnen kiezen om een abstract class te maken in plaats van een Interface.

Daarom vloek ik ook zo hard als iemand zo`n stomme fout maakt (vooral in een library die je moet gebruiken en je de source niet van hebt of kan aanpassen... bv Swing!)

[.oisyn]

Alarmnummer schreef op 05 September 2003 @ 10:43:
Ik zie dat het toch een heel interface verhaal is geworden

Zoals ik al hierboven heb beschreven is het voordeel aan een interface dat je compiletime kan afdwingen dat een interface alleen een beschrijving is, en geen implementatie. Bij een class kan je dit onmogelijk voor elkaar krijgen. En idd, het verschil tussen een puur abstracte class en een interface is klein, maar waarom zie ik dan zoveel c++ code waarin ze een interface maken en ook meteen maar wat implementatie in plaatsen?

Door het kleinste beetje implementatie toe te voegen (die misschien wel erg voor de hand ligt), maak je het een stuk lastiger om allerlei design patterns te gebruiken zoals bv de decorator, proxy omdat je geen puur abstracte classes tot je beschikking hebt,

waarom zou er geen implementatie mogen zijn, die het de gebruiker iets makkelijker maakt? Ik zal een voorbeeld geven:

C++:

class IetsMetEenNaam
{
public:
    // eerst de pure interface
    virtual const std::string & getVoornaam () = 0;
    virtual const std::string & getAchternaam () = 0;

    // dan een extra functie, zodat het wat makkelijker wordt
    std::string getVolledigeNaam ()
    {
        return getVoornaam () + " " + getAchternaam ();
    }
};

wat is daar mis mee? Een object die deze interface implementeerd moet dus een voornaam en een achternaam kunnen leveren. Voor de gebruikers van de interface is er wat extra functionaliteit zodat ze de volledige naam op kunnen vragen. Deze extra functionaliteit maakt ook gewoon gebruik van de pure interface zelf, en doet dus verder ook niets af aan het gebruik ervan.

Natuurlijk, in Java moet je hier een abstract class maken omdat je anders geen implementatie kan leveren van getVolledigeNaam (), waardoor het ook niet meer mogelijk is om een klasse te maken die deze interface implementeerd, en ook nog eens overerft van een andere klasse, en dat is natuurlijk erg fout.

Maar een taal als C++ heeft die limiet niet, dus waarom zou het dan niet mogen? Ik ken het decorator pattern niet, maar de proxy is nog gewoon mogelijk, en volgens mij gewoon elke andere design pattern. Niets mis mee toch?

[MSalters]

Ej. .oisyn, je kiest wel weer een ongelukkig voorbeeld. Namen komen in teveel varianten, en voornaam+' '+achternaam is lang niet altijd de beste opbouw. Maak die functie dan op z'n minst virtual, voor al die gevallen waarin het een zinnige implementatie is.
class Adelijk kan dan in Adelijk::getVolledigeNaam() gewoon titel + IetsMetEenNaam::getVolledigeNaam() retourneren.

[ Voor 4% gewijzigd door MSalters op 05-09-2003 20:29 ]

[.oisyn]

Je hebt helemaal gelijk, maar het was maar een voorbeeld