[.NET] Interfaces en constructors

[Anoniem: 29173]

Beste devvers,

Kort maar krachtig:
- Het is niet mogelijk om constructors te definieren in interfaces.
- Het gebruik van abstracte klassen vind ik niet the way to go (ik wil immers geen gedrag of skelet vastleggen, alleen verplichte functionaliteit in de zin van methoden, bv: connect, openDo(adrr), closeDo(adrr), setAo(adrr, val) etc.)

Ik heb een bestaande applicatie en wil het mogelijk maken voor derden om bijvoorbeeld andere IO drivers te schrijven (nu zijn mensen afhankelijk van de hardware die ik voorhanden heb). Nu is het probleem de parameters die ik via de constructor meegeef.

In een interface kun je geen constructors definieren... Als je interfaces op deze manier gebruikt heb je dus bijvoorbeeld properties voor 'settings' die je object nodig heeft. Bijvoorbeeld: een lamp object kan in de software niet functioneren zonder dat deze een io-controller object aangewezen krijgt.

Hoe geef je op een juiste manier aan welke van deze 'settings' een waarde MOETEN krijgen (in de interface)? Kan dit enkel in dcumentatie of hebben ze hier iets slims op bedacht? Of is dit toch een stukje 'gedrag' en moet ik voor abstracte klassen gaan?

[Janoz]

De gebruiker van de interface heeft toch helemaal niks te maken met de inner workings en het aanmaken van dat object? Waarom moet dat object altijd verplicht settings mee krijgen? Het zou toch ook heel goed kunnen dat ik een lamp object weet te implementeren die geen io-controler nodig heeft?

[Cyphax]

Janoz schreef op dinsdag 20 mei 2008 @ 16:43:
Het zou toch ook heel goed kunnen dat ik een lamp object weet te implementeren die geen io-controler nodig heeft?

Of dat je een lamp definieert die een io-controller op een andere manier regelt ofzo. Inderdaad: het gaat er alleen maar om dat het object bepaalde methods/properties heeft, hoe die zijn geimplementeerd is niet zo heel interessant voor degene die ermee moet communiceren.

[Haan]

Als je properties definiëert in je interface, moeten die toch sowieso geïmplementeerd worden? of zit ik nou verkeerd te denken

[Cyphax]

Haan schreef op dinsdag 20 mei 2008 @ 16:48:
Als je properties definiëert in je interface, moeten die toch sowieso geïmplementeerd worden? of zit ik nou verkeerd te denken

Maar hoe die aan hun waarde komen is weer niet interessant.

Je stelt in je startpost:

ik wil immers geen gedrag of skelet vastleggen, alleen verplichte functionaliteit in de zin van methoden

De constructor hoort daar niet bij.

[Anoniem: 29173]

Janoz schreef op dinsdag 20 mei 2008 @ 16:43:
De gebruiker van de interface heeft toch helemaal niks te maken met de inner workings en het aanmaken van dat object? Waarom moet dat object altijd verplicht settings mee krijgen? Het zou toch ook heel goed kunnen dat ik een lamp object weet te implementeren die geen io-controler nodig heeft?

Inderdaad... Als ik het op die manier bekijk ja.

Ben iets te gefocussed op mijn eigen implementatie to zien .

[Anoniem: 49627]

Anoniem: 29173 schreef op dinsdag 20 mei 2008 @ 16:36:
- Het is niet mogelijk om constructors te definieren in interfaces.

Het is vrij gangbaar om hiervoor een init(Context) methode voor te definieren. Het volgt uiteraard niet hetzelfde gedrag als een constructor maar ook een constructor dwingt geen correcte implementatie af.

Je zou er voor kunnen kiezen om twee of meerdere interfaces te definieren.
1 - voor je gewenste gedrag
2 - voor je dependencies (bijv. IOControllerAware, met een methode setIOController(Iocontroller))

[whoami]

Anoniem: 29173 schreef op dinsdag 20 mei 2008 @ 16:36:
Beste devvers,

Kort maar krachtig:

- Het gebruik van abstracte klassen vind ik niet the way to go (ik wil immers geen gedrag of skelet vastleggen, alleen verplichte functionaliteit in de zin van methoden, bv: connect, openDo(adrr), closeDo(adrr), setAo(adrr, val) etc.)

Je hoeft toch ook helemaal geen skelet vast te leggen ?

code:

public abstract class SomeThing
{
     public SomeThing( ... )
     {
        ..
     }

     public void CloseDo( .. )
     {
          CloseDoCore (...);
     }

     protected abstract void CloseDoCore ( ... );
}

Hier heb je ook helemaal geen skelet vastgelegd, en heb je gewoon een abstract class gemaakt die een bepaalde interface heeft, en je zorgt ervoor dat inheritors de abstracte methodes moeten implementeren.

Haan schreef op dinsdag 20 mei 2008 @ 16:48:
Als je properties definiëert in je interface, moeten die toch sowieso geïmplementeerd worden? of zit ik nou verkeerd te denken

Maar daarmee verplicht je niet dat dit object ook waardes krijgt voor die properties, en dat is wat de topicstarter wil. De topicstarter wil dat een bepaald object verplicht waardes toegekend krijgt voor bepaalde properties, maar dat kan je met properties niet afdwingen.

[ Voor 22% gewijzigd door whoami op 20-05-2008 17:04 ]

[pkuppens]

Anoniem: 29173 schreef op dinsdag 20 mei 2008 @ 16:36:
Beste devvers,

Kort maar krachtig:
- Het is niet mogelijk om constructors te definieren in interfaces.
- Het gebruik van abstracte klassen vind ik niet the way to go (ik wil immers geen gedrag of skelet vastleggen, alleen verplichte functionaliteit in de zin van methoden, bv: connect, openDo(adrr), closeDo(adrr), setAo(adrr, val) etc.)

Ik heb een bestaande applicatie en wil het mogelijk maken voor derden om bijvoorbeeld andere IO drivers te schrijven (nu zijn mensen afhankelijk van de hardware die ik voorhanden heb). Nu is het probleem de parameters die ik via de constructor meegeef.

In een interface kun je geen constructors definieren... Als je interfaces op deze manier gebruikt heb je dus bijvoorbeeld properties voor 'settings' die je object nodig heeft. Bijvoorbeeld: een lamp object kan in de software niet functioneren zonder dat deze een io-controller object aangewezen krijgt.

Hoe geef je op een juiste manier aan welke van deze 'settings' een waarde MOETEN krijgen (in de interface)? Kan dit enkel in dcumentatie of hebben ze hier iets slims op bedacht? Of is dit toch een stukje 'gedrag' en moet ik voor abstracte klassen gaan?

toon volledige bericht

Klinkt wel heel erg als een 'Factory' design pattern. Een klasse en/of subclasses verantwoordelijk maken voor het initialiseren van objecten. Begin hier maar eens te lezen:
http://www.dofactory.com/Patterns/Patterns.aspx

[Anoniem: 29173]

Klopt gebruik een factory pattern.

Leuke link maar heb ook op school gezeten ;-).

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 95% gewijzigd door Ruudjah op 01-12-2009 23:08 ]

[whoami]

Wat jij toont, is een factory method, en jouw 2de code-voorbeeld is 'pretty awfull' te noemen natuurlijk.

Als je een factory wilt definiëren met een interface, dan zit je al gauw aan het abstract factory pattern, en dat wil je gewoon niet met statics realiseren.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 01-12-2009 23:08 ]

[.oisyn]

Ruudjah schreef op dinsdag 20 mei 2008 @ 19:50:

C#:

Klant k = new Klant.createNew();

Wat niet kan. Klant is je interface. Je kunt een interface niet newen - het heeft immers geen implementatie.

[Anoniem: 49627]

Even iets te flauw doen

Java:

public class Test {
    public static void main(String args[]) {
        Klant k = new Klant.createNew();
    }
}

interface Klant {
    public static class createNew implements Klant {}   
}

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 133% gewijzigd door Ruudjah op 01-12-2009 23:09 ]

[.oisyn]

Wat nergens op slaat, omdat je dan al een nieuwe concrete Klant hebt gemaakt, waardoor createNew() overbodig wordt. Ik probeerde niet flauw te zijn met mijn opmerking, ik probeerde de kronkel in de denkwijze aan te tonen.

Dezelfde kronkel die de topicstarter ook heeft trouwens. Hij wil een constructor in een interface zodat hij een parameter kan accepteren. Maar al zou je een interface een constructor kunnen geven, dan nog heb je er niets aan omdat je je interface nooit creëert met new. Je creëert een afgeleide concrete klasse, en die heeft vervolgens de betreffende constructor om de parameter te accepteren, waardoor een eventuele constructor in de interface sowieso overbodig is. Het heeft namelijk weinig nut om in de interface vast te kunnen leggen hoe een klasse geconstruct kan worden - zodra je new doet moet je het concrete type al weten.

Wat tevens de reden is dat een static createNew() in de interface Klant onzinnig is. Die method weet nog niet welk concreet type hij moet instantieren. Een abstracte factory is dan een uitkomst (met een createNew() methode), die je weer implementeert om een ConcreteKlant te kunnen maken. En ja, als je dan een Klant wil maken via die interface dan kun je die ConcreteKlantFactory idd instantieren zodat je voorbeeld als volgt wordt:

Java:

Klant k = new ConcreteKlantFactory().createNew();

Maar dan is ConcreteKlantFactory al een klasse die je gewoon (ook) een static createNew() method kunt geven zodat je 'm niet eerst hoeft te instantieren. Maar ook dat is nutteloos, want je weet toch al wat voor Klant je gaat instantieren (een ConcreteKlant, anders gebruikte je de ConcreteKlantFactory niet), dus dan kun je net zo goed meteen new ConcreteKlant() doen in je code.

[ Voor 97% gewijzigd door .oisyn op 21-05-2008 00:44 ]

[pkuppens]

Anoniem: 29173 schreef op dinsdag 20 mei 2008 @ 17:34:
Klopt gebruik een factory pattern.

Leuke link maar heb ook op school gezeten ;-).

// Off topic?!

No pun intended hoor. De vraagstellers hier varieren van middelbare schoolprojectjes tot professionals.
Zelf met TU/e Wiskunde tot 1993, en flink wat jaartjes software design, toch pas recenter in aanraking gekomen met Design Patterns. Ik heb de indruk dat de kennis van Design Patterns hier het best vertegenwoordigd is bij recentere HBO'ers Informatica, dus ik heb zelf ook net de tijd, studie, opleidingsniveau misgelopen.
Ik kon dat bij jouw probleemstelling niet helemaal achterhalen.

Aan de moderators:
Mijn suggestie is om als aanbeveling in de Quickstart op te nemen bij voorkeur te vermelden wat ongeveer de technische kennis van de vraagsteller is. Dit helpt om te bepalen in welke termen antwoord gegeven kan worden.

In dit geval was me wel duidelijk dat ik het in ieder geval als oplossingsrichting kon aandragen.

// Slightly more on topic

Het roepen van 'Design Patterns' heeft in ieder geval wel genoeg andere antwoorden getriggerd

[.oisyn]

.edit: nvm

[ Voor 97% gewijzigd door .oisyn op 21-05-2008 10:56 ]

[EfBe]

Anoniem: 29173 schreef op dinsdag 20 mei 2008 @ 16:36:
Beste devvers,

Kort maar krachtig:
- Het is niet mogelijk om constructors te definieren in interfaces.
- Het gebruik van abstracte klassen vind ik niet the way to go (ik wil immers geen gedrag of skelet vastleggen, alleen verplichte functionaliteit in de zin van methoden, bv: connect, openDo(adrr), closeDo(adrr), setAo(adrr, val) etc.)

Het is belangrijk te begrijpen wat een interface is. Het is een type definitie. Binnen .NET heb je multiple-type inheritance en single implementation inheritance. Dit houdt in dat je dmv interfaces multiple inheritance mbt types hebt, maar je kunt maar van 1 implementatie erven.

Je kunt dus door interfaces te gebruiken meerdere types toekennen aan een implementatie (die zelf ook een interface heeft, nl. de class interface).

Een constructor heeft niets met een interface van doen, want een constructor is voor de implementatie en heeft niets met het type te maken: een type is een definitie van behavior, niet de implementatie van de behavior zelf.

Abstract classes worden vaak verward met interfaces: waarom moet je abstract classes gebruiken en niet interfaces en andersom? Abstract classes kunnen gezien worden als een basis implementatie van EEN type. Dit type kan voortkomen uit multiple-type inheritance of een nieuw type zijn, dat is aan jou. Als je dus de implementatie van een interface niet wilt voorschrijven, dan heb je niets aan abstract classes. Wil je een basisimplementatie bouwen zodat het gebruik van de interface makkelijker is, dan is het wel handig om een abstract class te maken. Het heeft wel als nadeel dat je dan niet nog eens van een andere class kunt erven.

Ik heb een bestaande applicatie en wil het mogelijk maken voor derden om bijvoorbeeld andere IO drivers te schrijven (nu zijn mensen afhankelijk van de hardware die ik voorhanden heb). Nu is het probleem de parameters die ik via de constructor meegeef.

In een interface kun je geen constructors definieren... Als je interfaces op deze manier gebruikt heb je dus bijvoorbeeld properties voor 'settings' die je object nodig heeft. Bijvoorbeeld: een lamp object kan in de software niet functioneren zonder dat deze een io-controller object aangewezen krijgt.

Hoe geef je op een juiste manier aan welke van deze 'settings' een waarde MOETEN krijgen (in de interface)? Kan dit enkel in dcumentatie of hebben ze hier iets slims op bedacht? Of is dit toch een stukje 'gedrag' en moet ik voor abstracte klassen gaan?

Dit kan niet in een interface in de huidige .NET talen, want dit is runtime program flow materiaal en niet gerelateerd aan een contract/type definitie.

M.a.w.: je documenteert dit en checkt het at runtime en als iets niet klopt dan throw je een exception. Je kunt immers niet at compile time checken of in een sequentiele serie statements jouw driver wel alle waarden heeft gekregen, zonder code analyse.

Verder moet je programmeurs niet behandelen als kinderen: als mensen denken een driver te kunnen maken, dan moeten ze dat maar goed doen, ze denken het toch te kunnen? M.a.w.: je documenteert wat nodig is at runtime en je checkt in jouw host app of de driver zichzelf goed initialiseert. Doet de driver dat niet, dan gooi je een exception en disable je de driver.