Abstract class versus Interface

[Scare360]

Gisteren "in een milde discussie" met Alarmnummer kwam dit item weer naar boven. Wanneer abstractie of interfaces te gebruiken. In mijn optiek is dat vrij simpel en wel:

Indien er sprake is van:

Interface gebruiken wanneer je het gedrag van een klasse minimaal wilt vastleggen, het contract tussen diegene die jouw als interface implementeerd.

Abstract klassen zijn een bak met abstractie, daar waar een interface veel verder/dieper zou specificeren. De mogelijkheid default gedrag te implementeren zorgt voor lichtgewichte aftreksels van abstracte klassen.

Een vogel is bv niets, een arend daarentegen weer wel (uhm naja):

code:

abstract class AbstractVogel {}

class Arend : Vogel {}

ipv

code:

interface IVogel {}

class Arend : IVogel {}

Mijn ervaring met de_wat_grotere frameworks waar meerdere mensen mee werken is dat interfaces de zaak snel onduidelijk maken. Zeker als diegenen die aanpassingen maakt een goed beeld heeft van de top hierarchie kan deze al snel op gang komen op basis van de abstracte structuur, waar interfaces vaak te snel te veel detail bevatten mb.t. implementatie aspecten.

Ik ben dan ook voor structuur aanbrengen met abstractie en contracten leggen m.b.v. interfaces, anders gezegd: de interactie met de klasse borgen.

Zie ook deze discussie:
Design van een errorlogger.

Iemand een mening?

[mbravenboer]

Abstracte klassen: delen van gezamelijke implementatie
Interfaces: specificatie van gezamelijke interface

duidelijker kan niet .

[mbravenboer]

Merk trouwens op dat het dus geen concurrerende constructies zijn: bij het gebruik van abstracte klassen kan je nog steeds interfaces gebruiken om de gezamelijke interfaces te beschrijven. Abstracte klassen zijn puur voor het delen van op zichzelf niet nuttige implementatie (als het op zichzelf wel nuttig zou zijn, zou je gewone klassen gebruiken).

[Alarmnummer]

Ik ben idd voor het gebruik van interfaces omdat je je niet onnodig hoeft vast te leggen aan een basis class. Als je bv een decorator zoals bv een proxy wilt maken, dan is het superhandig als alles is opgezet vanuit interfaces. Het enigste punt waar ik nog wel eens een uitzondering hierop maak zijn leaves van een class hierarchie. Hierbij wil ga ik nog wel eens direct een class opzetten zonder dat ik hiervoor een interface aanmaak. De reden dat ik dit doe is om de complexiteit binnen de perken te houden.

En als je je dan gaat afvragen op wat voor manier je dan toch code kan sharen, kan ik hier ook wel antwoord op geven. Ik maak meestal wel abstract of default implementaties aan die je kan gebruiken. Hierdoor heb je het gemak van sharen, maar de vrijheid van interfaces.

[Alarmnummer]

mbravenboer schreef op 02 april 2003 @ 11:19:
Abstracte klassen: delen van gezamelijke implementatie
Interfaces: specificatie van gezamelijke interface

duidelijker kan niet .

Maar dan moet je er wel duidelijk bij vermelden dat je niet 'delen van een gemeenschappelijke implementatie' mag misbruiken voor 'de specificatie van een gezamelijke interface'. Dit zijn 2 zeer verschillende dingen, en dat is volgens mij ook het probleem van paulgielens.

[ Voor 5% gewijzigd door Alarmnummer op 02-04-2003 11:26 ]

[whoami]

Als bepaalde implementatie-details terugkomen in de inherited classes, dan is het logisch dat je een abstracte class kiest.
Ook als je membervariables hebt die in alle afgeleide types voorkomen kan je die dmv een abstracte class beschikbaar stellen.

Over Interface inheritance vs Implementation inheritace wordt het volgende gezegd in het GoF boek:

Class inheritance is basically just a mechanism for extending an application's functionality by reusing functionality in parent classes. It lets you define a new kind of object rapidly in terms of an old one. It lets you get new implementations almost for free, inheriting most of what you need from existing classes.

However, implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. Why? Because polymorphism depends on it.

When inheritance is used carefully (some will say properly), all classes derived from an abstract class will share its interface. This implies that a subclass merely adds or overrides operations and does not hide operations of the parent class. All subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class.

There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes:

Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.

Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface.
This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design:

Program to an interface, not an implementation.

toon volledige bericht

[Scare360]

Nou ff een praktisch voorbeeld, ik heb een boom met knopen, maar de knopen zijn alles van een ander soort. Een hoofdknoop heeft subknopen welke weer verbonden zijn met een hoofdknoop dus:

subknoopA->hoofdknoopA->subknoopA->hoofdknoopB->subknoopB

Om zo'n boom af te fietsen ga je polymorfisme gebruiken:

code:

// Root
AbstractSubknoop mySk = new subKnoopA();

// loopen... recursief aanroepen enzo
foreach (AbstractSubKnoop sK in mySk.Parent.Children)
{}

Iets wat je in een objectgraph tegen komt.
Abstractie of interfaces?

[ Voor 3% gewijzigd door Scare360 op 02-04-2003 11:34 ]

[whoami]

Delen die knopen bepaalde implementaties of niet?
Zijn er member variablen die in al deze knopen terugkomen?

Als je op beide vragen neen antwoord, dan zou ik voor interfaces gaan.

[Alarmnummer]

Het is me niet helemaal duidelijk of hoofdknoopB ook een subtype is van subknoopA.

[edit]

Om zo'n boom af te fietsen ga je polymorfisme gebruiken:

visitor guide`s natuurlijk

[ Voor 43% gewijzigd door Alarmnummer op 02-04-2003 11:37 ]

[Scare360]

Sorry, alle subknopen zouden dezelfde methodes implementeren alleen ander gedrag dus. Ook delen ze bv properties als ID, Naam, Gewicht.