🚀 go-pugleaf

> Daarom had ik gedacht aan een
> abstracte klasse maar dan heb ik geen controle dat alle methode'n worden
> ge�mplementeerd.

Als je een class een abstract class laat extenden, en die extended class 
is zelf niet abstract MOET je ALLE nog abstracte methods (zowel van de 
direct subclassed abstract class als van evt. 'hogere' abstract 
classes/interfaces) implementeren. Ziedaar je controle.

> Het gaat er hem om dat ik een interface/abstracte klasse wil maken waar ik
> definieer welke methoden ik heb voor het importeren van bestanden. In de
> klasse die de interface implementeerd of de abstracte klasse verlengd
> schrijf ik dan de effectieve broncode voor die methode. Wanneer ik een
> abstracte klasse gebruik ben ik niet zeker dat bij het maken van een andere
> klasse ook alle methoden worden ge�mplementeerd en dat is hier wel nodig dus
> als iemand een idee heeft of de gulden middenweg?

Dat is dus wel zo. Waar jij volgens mij bang voor bent is het scenario 
zoals je dat bijvoorbeeld bij Servlets aantreft; in HttpServlet is elke 
method al ge�mplementeerd met dummy inhoud. Als je in een subclass dan 
niet oplet sla je mogelijk methods over (want een override is nooit 
verplicht). Maar dat is hier dus niet aan de hand; een concrete class 
kan niet ��n abstract method meer hebben.

Volgens mij is een abstract class dus wel degelijk je oplossing. Het in 
een andere posting geschetste scenario waarbij een interface deels wordt 
ge�mplementeerd door een abstracte class, die vervolgens weer wordt 
extended door ��n of meerdere "eind"-subclasses, kom je veel tegen als 
alle "eind"-subclasses een aantal methods gezamenlijk kunnen gebruiken. 
Zulke methods (met name utilities, bestandsafhandeling, etc.) neem je 
dan als niet-abstract in de abstracte class op.

Hopelijk brengt dit je wat verder.

Groeten,
Joost van Stuijvenberg