Classdiagram met interfaces

[Verwijderd]

Ik maak graag mijn classes op basis van interfaces die definieren hoe de class er uit moet zien. Ik gebruik daar ook een case-tool voor, zodat de code automatisch gegenereert wordt.

Maar nu heb ik dus het volgende model gemaakt (simpel voorbeeldje):



Hierin is dus te zien dat de operations van de classes Opleiding en Student zijn gedefinieerd in hun interfaces. Een interface heeft geen attributes, dus die zijn in de class gedefinieerd.

code:

IStudent Jan = new Student();

MessageBox.Show(Jan.Registreer().ToString());

Maar hoe komt het dat ik dit soort modellen nooit zie, als ik bijvoorbeeld op Google zoek ernaar. Is dit zo ongebruikelijk wat ik doe?

[Verwijderd]

Waarom definieer je weer nieuwe functies/properties in de klasse die de interface implementeert? Voor zover ik weet is het klasse diagram van een interface gelijk aan de implementerende klasse...

[Verwijderd]

Verwijderd schreef op vrijdag 03 februari 2006 @ 16:05:
Waarom definieer je weer nieuwe functies/properties in de klasse die de interface implementeert? Voor zover ik weet is het klasse diagram van een interface gelijk aan de implementerende klasse...

Dat ligt aan de casetool.

Ik heb begrepen dat je geen attributes mag declareren in een interface daarom maak ik die aan in de class.
En properties kan ik alleen aanmaken zodra ik een attribute aanmaak, dus dat lukt niet in een interface.

[RayNbow]

Verwijderd schreef op vrijdag 03 februari 2006 @ 16:05:
Waarom definieer je weer nieuwe functies/properties in de klasse die de interface implementeert? Voor zover ik weet is het klasse diagram van een interface gelijk aan de implementerende klasse...

Een klasse kan meerdere interfaces implementeren, dus waarom moet het diagram van een klasse gelijk zijn aan die van een interface?

[Verwijderd]

RayNbow schreef op vrijdag 03 februari 2006 @ 16:15:
[...]

Een klasse kan meerdere interfaces implementeren, dus waarom moet het diagram van een klasse gelijk zijn aan die van een interface?

Hmms nu ik erover nadenk slaat het nergens op wat ik zei

[whoami]

In jouw voorbeeld zie ik niet direct nut van het gebruik van interfaces. (Misschien in de toekomst wel )
Heb je nog classes die dezelfde interface implementeren ?

[Verwijderd]

whoami schreef op vrijdag 03 februari 2006 @ 16:29:
In jouw voorbeeld zie ik niet direct nut van het gebruik van interfaces. (Misschien in de toekomst wel )
Heb je nog classes die dezelfde interface implementeren ?

Er zijn geen classes die dezelfde interface implementeren.

Op mijn vorige project werd het dus zo gebruikt, omdat 1 iemand dan de interfaces definieerde en vervolgens iemand anders (of dezelfde persoon) de implementatie schreef. Dat werd gebruikt omdat niet iedereen even goed was in het verzinnen van de operators en attributen van de classes.

Maar bij nader inzien is dat overbodig als je gebruik maakt van een casetool om eerst eens rustig de classes incl. operators en attributen op te schrijven en vervolgens de code te genereren, waarne de code verder door de developers wordt ingevuld.

[Kwistnix]

Het grote voordeel in jouw voorbeeld is dat je bijv. een lijst van objecten kan bijhouden die allemaal de interface IStudent implementeren, terwijl die objecten qua implementatie totaal uiteen kunnen lopen. Op die manier weet je zeker dat je op ieder object in de lijst altijd de gedeelde methoden kan aanroepen met een vaste signature. Als je een dergelijke constructie niet gebruikt dan snap ik het voordeel van het gebruik van een common interface niet helemaal.

[ Voor 25% gewijzigd door Kwistnix op 03-02-2006 17:10 ]

[r5d]

Verwijderd schreef op vrijdag 03 februari 2006 @ 15:33:Is dit zo ongebruikelijk wat ik doe?

Ja
Interfaces dien je alleen in bijzondere gevallen te gebruiken, daar waar ze ook echt iets toevoegen. Een klasse heeft in de OO wereld namelijk zelf al een "interface". De access modifiers (pirvate/public/etc) definieren namelijk al hoe je klasse er voor de buitenwereld uitziet.

You use an interface to define a protocol of behavior that can be implemented by any class anywhere in the class hierarchy. Interfaces are useful for the following:

* Capturing similarities among unrelated classes without artificially forcing a class relationship
* Declaring methods that one or more classes are expected to implement
* Revealing an object's programming interface without revealing its class
* Modeling multiple inheritance, a feature of some object-oriented languages that allows a class to have more than one superclass

_{Bron: http://java.sun.com/docs/...a/concepts/interface.html}

[whoami]

FallenAngel666 schreef op vrijdag 03 februari 2006 @ 17:00:
Het grote voordeel in jouw voorbeeld is dat je bijv. een lijst van objecten kan bijhouden die allemaal de interface IStudent implementeren, terwijl die objecten qua implementatie totaal uiteen kunnen lopen. Op die manier weet je zeker dat je op ieder object in de lijst altijd de gedeelde methoden kan aanroepen met een vaste signature. Als je een dergelijke constructie niet gebruikt dan snap ik het voordeel van het gebruik van een common interface niet helemaal.

Eens, vandaar dat ik het ook vroeg.

[Verwijderd]

Het is duidelijk. De manier van werken die ik aangaf heeft weinig toegevoegde waarde. Die ga ik niet meer toepassen.


Toch nog even het volgende:

PimpDiddy schreef op vrijdag 03 februari 2006 @ 17:13:
[...] Interfaces are useful for the following:

* Capturing similarities among unrelated classes without artificially forcing a class relationship
* Declaring methods that one [...] class [is] expected to implement
* Revealing an object's programming interface without revealing its class
* Modeling multiple inheritance, a feature of some object-oriented languages that allows a class to have more than one superclass

De eerste vetgedrukte opties is eigenlijk toch wat er gebeurt in mijn voorbeeld?
De tweede snap ik niet helemaal, omdat je alleen maar een object kan instantiëren op basis van een class en niet op basis van een interface. Maar misschien moet ik daar nog wat dieper in duiken.

[RayNbow]

Verwijderd schreef op vrijdag 03 februari 2006 @ 20:21:
[...]

De tweede snap ik niet helemaal, omdat je alleen maar een object kan instantiëren op basis van een class en niet op basis van een interface. Maar misschien moet ik daar nog wat dieper in duiken.

Als je iets hebt als het volgende (simpel voorbeeldje):

Java:

public class Studenten {
    public static IStudent getSomeStudent() {
        /* retourneer een of ander object die IStudent implementeert */
    }
}

...en zie het volgende:

Java:

IStudent student = Studenten.getSomeStudent();

Nu kun je met student alleen de methoden gebruiken van de interface IStudent. Bij de overige methoden van het object kun je niet komen (tenzij je gaat casten en zo).

Edit:
Zie bijv. het Read-Only Interface pattern, kort beschreven in dit PDFje

[ Voor 11% gewijzigd door RayNbow op 03-02-2006 20:58 ]

[EfBe]

Interfaces zijn nuttig om typen te definieren zonder implementatie, en ze daarna voor bv multiple-type inheritance te gebruiken of om te zorgen dat een class kan worden gebruikt in een routine die een bepaald type verwacht.

Als dat dus niet aan de orde is in je code, hoef je geen interfaces te definieren en kun je gewoon met classes werken.

[NoControl]

Misschien beetje off topic, maar welk tool heb je gebruikt om dat diagram te maken?

[Verwijderd]

Ik heb Enterprise Architect gebruikt om het model te maken. Versie 4.6 om precies te zijn, das nog een oude versie, ze zijn nu al bij versie 6.0.

Het kan ook gebruikt worden voor code generation en reverse engineering.

[ Voor 45% gewijzigd door Verwijderd op 03-02-2006 23:26 ]

[Apache]

EfBe schreef op vrijdag 03 februari 2006 @ 22:23:
Interfaces zijn nuttig om typen te definieren zonder implementatie, en ze daarna voor bv multiple-type inheritance te gebruiken of om te zorgen dat een class kan worden gebruikt in een routine die een bepaald type verwacht.

Als dat dus niet aan de orde is in je code, hoef je geen interfaces te definieren en kun je gewoon met classes werken.

Soms kan het wel nuttig zijn als je in je analyse hebt vastgesteld dat de toekomstige variatie zich daar zal gaan bevinden, dan kan je gewoon coden naar interface.

Praktisch kan je dan in je code IStudent s = new <jeimplementatie> gebruiken en ook in je methodes die het ontvangen etc, maar later bij andere implementaties heb je veel minder werk om overal viarablenamen te gaan wijzigen.

[EfBe]

Apache schreef op zaterdag 04 februari 2006 @ 00:20:
[...]


Soms kan het wel nuttig zijn als je in je analyse hebt vastgesteld dat de toekomstige variatie zich daar zal gaan bevinden, dan kan je gewoon coden naar interface.

Praktisch kan je dan in je code IStudent s = new <jeimplementatie> gebruiken en ook in je methodes die het ontvangen etc, maar later bij andere implementaties heb je veel minder werk om overal viarablenamen te gaan wijzigen.

Dat klopt, maar niet alle situaties zijn geschikt hiervoor. Het nadeel van interfaces is dat je ze niet kunt wijzigen. Als je bv in v2.0 een nieuwe method wilt toevoegen en de code zou zijn geschreven tegen base classes aan, dan was dat geen punt geweest. Werk je met interfaces dan moet je een nieuwe interface definieren en dat kan na verloop van tijd een puinhoop worden.

MS heeft om deze reden ook een tijdje terug de beslissing genomen om in .NET bv alleen daar interfaces te gebruiken waar base classes niet beschikbaar zijn, en op alle andere plekken alleen base classes te gebruiken.