[OO] Interfaces idee

[mbravenboer]

Tijdens m'n dagelijkste programmeer-werkzaamheden kwam ik op een aardig idee wat je zou kunnen toepassen in OO-talen . Het heeft te maken met interfaces. Wat dat zijn hoef ik hopelijk niet uit te leggen .

Mijn idee heeft te maken met het combineren van interfaces. Als je veel met kleine interfaces werkt komt het vaak voor dat je eigenlijk wilt opgeven dat een methode argument aan verschillende interfaces moet voldoen. Op dit moment moet je dat doen door een nieuw type te maken die beide interfaces extend of implementeert. Maar dat is totaal overbodig en kan een explosie aan combinaties veroorzaken.

Even een voorbeeldje . Stel bijvoorbeeld dat je deze interface hebt:

code:

public interface Runnable
{
    public void run();
}

(ja die kennen we ).

en bijvoorbeeld deze:

code:

public interface Stoppable
{
    public void stop();
}

Als je nu een methode wilt schrijven die een object vereist die Runnable en Stoppable is, moet je een nieuwe interface maken (sorry voor de onzinnge naam):

code:

public interface RunnableStoppable extends Runnable, Stoppable
{
}

Nu kan je dus opgeven dat je een RunnableStoppable wilt hebben.

Goed, dat is dus niet zo'n groot probleem, maar stel nu eens dat we ook nog een interface Suspendable hebben:

code:

public interface Suspendable
{
    public void suspend();
}

en een interface Resumable:

code:

public interface Resumable
{
    public void resume();
}

Wel, je ziet de bui waarschijnlijk al hangen! Ga dit maar eens allemaal combineren: RunnableSuspendable, RunnableSuspendableStoppable, RunnableResumable en ga zo nog maar een stuk of 20 keer door . Vaak zal er in dit geval dus gekozen worden voor ranzige casts of niet atomaire interfaces.

Dit is natuurlijk een zeer extreem en wellicht onzinnig voorbeeld, maar de bedoeling is duidelijk: je moet aan kunnen geven dat een methode aan meerdere interfaces moet voldoen!

Bijvoorbeeld

code:

public void doSomething(Runnable and Cancelable r);

of

code:

public void doSomething(Suspendable and Resumable r);

Dit lijkt mij een super toevoeging voor talen als C# en Java en het is vrij logisch in te zien dat hier geen enkel bezwaar tegen is. Grappig om te zien dat ze bij C# aan allerlei suiker hebben gedacht, maar niet hier aan. Het zal waarschijnlijk wel problemen opleveren voor de bytecode, maar desnoods kan er at-compile time een gecombineerde interface worden gegenereerd.

Uiteraard gaat dit in deze talen alleen op voor interfaces, het is onzinnig om implementaties van verschillende klassen te vereisen. Er is immers geen multiple inheritance.

Vinden jullie het ook zo'n stoer idee?
Kent iemand dit uit andere talen? (ik niet namelijk)

[D2k]

op zich wel een geinig id, maar als het er nog niet is waarom zou het er dan nog niet zijn vraag ik me dan altijd af?
Is het wel zo "handig" als jij nu doet voorkomen of zijn er nadelen aan verbonden?

ik heb het iig imho ook nog nergens gezien iig.

[TheDane]

okee, misschien hele stomme opmerking (ik ben nog niet zo'n held in OO programmeren) maar is dit niet gewoon een kwestie van inheritance ?

ik geloof dat ik ooit eens geleerd heb dat je een class gewoon de eigenschappen van meerdere parents kan laten erven.

dan ben je er toch? of overzie ik iets heel triviaals? zo ja, enlighten me please

_{leg voor de zekerheid toch maar eens uit wat interfaces zijn aub}

[drm]

mbravenboer:
Vinden jullie het ook zo'n stoer idee?
Kent iemand dit uit andere talen? (ik niet namelijk)

Idd een stoer idee, ja!

Aan de andere kant wordt typechecking wel redelijk ingewikkeld, zo voor de compiler, istnie?

En bestaat er dan ook zoiets als:

code:

public void doSomething ( Runnable or Resumable )

Oh, nee, dat is bij nader inzien helemaal niet interessant....

Zijn iig een hoop vragen over te bedenken, maar ik vind 't wel geinig
* drm moet helaas weer gauw aan het werk...

[Canard]

Ik ben sinds een jaar bezig met Java en het bevalt mij zeer goed. Ik gebruik het op m'n werk maar soms ook om wat te hobby'en. Ben net bezig met wat design patterns...
Jouw topic trok mijn aandacht doordat ik iets tegenkwam wat op te lossen is met het "tie mechanism". ook iets met interfaces...
Ik heb dus nog niet veel praktische ervaring maar mijn doel is om Java (en OO) door en door te kennen...

Voor zover ik kan oordelen klinkt jouw idee wel goed!

[Tomatrix]

Op donderdag 31 januari 2002 13:49 schreef TheDane het volgende:
okee, misschien hele stomme opmerking (ik ben nog niet zo'n held in OO programmeren) maar is dit niet gewoon een kwestie van inheritance ?

Maar dan zit je vast aan een concreet type, en dat wil je hier juist niet.

Vieze oplossing zou evt. zijn:

code:

public void doSomething (Runnable r, Stoppable s) {
   if (r != s) {
    throw ...;
   }
}

Ik kan me nu zo 1,2,3 niet bedenken waarom ze het er niet in hebben gestopt.

[Canard]

Op donderdag 31 januari 2002 13:49 schreef TheDane het volgende:
okee, misschien hele stomme opmerking (ik ben nog niet zo'n held in OO programmeren) maar is dit niet gewoon een kwestie van inheritance ?

ik geloof dat ik ooit eens geleerd heb dat je een class gewoon de eigenschappen van meerdere parents kan laten erven.

dan ben je er toch? of overzie ik iets heel triviaals? zo ja, enlighten me please

_{leg voor de zekerheid toch maar eens uit wat interfaces zijn aub}

Dat heet multiple inheritance maar volgens mij zit dat standaard niet in Java...

[mbravenboer]

D2k: op zich wel een geinig id, maar als het er nog niet is waarom zou het er dan nog niet zijn vraag ik me dan altijd af?

Ach, als je alle ideeen maar niet probeert omdat ze er nog niet zijn komen we natuurlijk niet veel verder .

Is het wel zo "handig" als jij nu doet voorkomen of zijn er nadelen aan verbonden?

Probeer ze maar te vinden

[D2k]

mbravenboer: Ach, als je alle ideeen maar niet probeert omdat ze er nog niet zijn komen we natuurlijk niet veel verder .

je begrijpt wel hoe ik het bedoelde uiteraard
maar idd als er niemand een veradering doorvoert gebeurt het nooi

Probeer ze maar te vinden

mjah ........

[mbravenboer]

TheDane: okee, misschien hele stomme opmerking (ik ben nog niet zo'n held in OO programmeren) maar is dit niet gewoon een kwestie van inheritance ?

Nee, dat is juist het punt . Ik wil geen interface maken die verschillende interface samentrekt tot 1 nieuwe..

ik geloof dat ik ooit eens geleerd heb dat je een class gewoon de eigenschappen van meerdere parents kan laten erven.

Dat kan idd als je multiple inheritance hebt (het zou hier om multiple inheritance van interfaces gaan, wat Java wel heeft), maar dat is niet relevant: ik wil helemaal geen nieuw type maken.

leg voor de zekerheid toch maar eens uit wat interfaces zijn

Hum das een beetje lastig.... Met een interface definieer je een soort type. Je geeft aan welke functionaliteit dit type heeft via methoden in de interface. Je implementeert deze methoden echter niet. Concrete klassen moeten namelijk deze interface implementeren. Je kunt zo een hele verzameling implementaties via dezelfde interface gebruiken, en dat is stoer .

[mbravenboer]

drm: Idd een stoer idee, ja!

Dacht ik ook .

Aan de andere kant wordt typechecking wel redelijk ingewikkeld, zo voor de compiler, istnie?

Mwah, het wordt wat lastiger ja, maar ik vind sowieso dat de complexiteit van tools die nodig zijn voor een taal beter niet een excuus zou moeten zijn om de taal aan te passen of te beperken . Een compiler hoeft alleen maar geschreven te worden, een taal wordt over de hele wereld gebruikt.

En bestaat er dan ook zoiets als (or)

Dasniezo zinvol denk ik idd . Tenzij ze gemeenschappelijke methoden hebben en de interface dus eigenlijk hetzelfde voorstellen, maar een andere naam hebben. Een Adapter (design pattern) kan dat echter zo oplossen.

[mbravenboer]

Tomatrix: Vieze oplossing zou evt. zijn

Idd, dat is een oplossing die ook weleens gebruikt heb. Erg vies idd :

[Tomatrix]

Heb misschien een probleempje gevonden, hier een klasse met de volgende methoden:

code:

public void doSomething (Runnable r) {
   ...;
}

public void doSomething (Stoppable s) {
   ...;
}

public void doSomething (Runnable And Stoppable rs) {
   ...;
}

Is hier nog wel duidelijk welke methode aangeroepen moet worden?

[TheDane]

Op donderdag 31 januari 2002 14:09 schreef mbravenboer het volgende:

[..]

Nee, dat is juist het punt . Ik wil geen interface maken die verschillende interface samentrekt tot 1 nieuwe..
[..]

Dat kan idd als je multiple inheritance hebt (het zou hier om multiple inheritance van interfaces gaan, wat Java wel heeft), maar dat is niet relevant: ik wil helemaal geen nieuw type maken.
[..]

Hum das een beetje lastig.... Met een interface definieer je een soort type. Je geeft aan welke functionaliteit dit type heeft via methoden in de interface. Je implementeert deze methoden echter niet. Concrete klassen moeten namelijk deze interface implementeren. Je kunt zo een hele verzameling implementaties via dezelfde interface gebruiken, en dat is stoer .

uhh, okeeeejjjj ...

snap 't half. genoeg om te vragen: wat is het voordeel hiervan? als 't dus zou kunnen wat jij zo graag wilt ...

[edit] thanks for reply

[mbravenboer]

Tomatrix: Heb misschien een probleempje. Is hier nog wel duidelijk welke methode aangeroepen moet worden?

Het lijkt inderdaad onduidelijk, maar het is niet minder duidelijk dan de huidige situatie.

Neem deze code maar eens:

code:

public class Test
{
    public static void main(String[] ps)
    {
      TestClass test = new TestClass();

      doSomething(test);
    }

    public static void doSomething(TestInterface1 i)
    {
      System.out.println("1");
    }

    public static void doSomething(TestInterface2 i)
    {
      System.out.println("2");
    }
}

interface TestInterface1
{
}

interface TestInterface2
{
}

class TestClass implements TestInterface1, TestInterface2
{
}

Als je dit compileert:

code:

martin@linux:~ > javac Test.java
Test.java:7: reference to doSomething is ambiguous, 
both method doSomething(TestInterface1) in Test and 
method doSomething(TestInterface2) in Test match
      doSomething(test);
      ^

Je ziet dat de compiler hier aan de bel trekt, maar hier is wat anders aan de hand. Voor de duidelijkheid heb ik het toch opgenomen.

Vergelijk het eens met deze code, die wel goed compileert:

code:

public class Test
{
    public static void main(String[] ps)
    {
      TestInterface1 test = new TestClass();

      doSomething(test);
    }

    public static void doSomething(TestInterface1 i)
    {
      System.out.println("1");
    }

    public static void doSomething(TestInterface2 i)
    {
      System.out.println("2");
    }

    public static void doSomething(TestClass c)
    {
      System.out.println("3");
    }
}

interface TestInterface1
{
}

interface TestInterface2
{
}

class TestClass implements TestInterface1, TestInterface2
{
}

Hier komt uit:

code:

martin@linux:~ > java Test
1

Er wordt dus altijd gekozen voor het gedeclareerde type van de parameter die je meegeeft.

Het leuke is nu dat er dus helemaal geen nieuwe ambiguiteit is omdat het implementeren van twee interface ook een type is.


Neem dit stukje code:

code:

public void method1( Runnable&Stoppable r)
{
   do(r);
}

public void do( Runnable  r) {}
public void do( Stoppable r) {}
public void do( Runnable&Stoppable r) {}

Er is nu niet meer onduidelijkheid dan in mijn wel compilerende voorbeeld. r is namelijk van het type Runnable&Stoppable en dus zal de 3e variant worden aangeroepen.

In dit geval:

code:

public void method1( Runnable&Stoppable r)
{
   do(r);
}

public void do( Runnable  r) {}
public void do( Stoppable r) {}

Is er weer ambiguiteit en zal de compiler waarschuwen. Dit komt overeen met mijn eerste voorbeeld.

Merk op dat je zo dus eigenlijk ook variabelen moet kunnen declareren:

code:

public void method1(...)
{
   Runnable&Stoppable r = new TestClass();
}

Alles past dus keurig netjes in elkaar .

[D2k]

mbravenboer: Mooi verhaal

kan der zo 1-2-3 geen speld tussen krijgen

[mbravenboer]

TheDane: wat is het voordeel hiervan? als 't dus zou kunnen wat jij zo graag wilt ...

Tja, dat is toch al aardig aan bod gekomen? Je hoeft geen interfaces te gaan combineren tot nieuwe interfaces (wat dus tot een explosie van interfaces kan leiden) en je hoeft geen workaround te gebruiken zoals casts of twee argumenten meegeven (zoals Tomatrix liet zien). Ook hoef je minder snel 'dikke' interfaces te definieren. Atomaire interfaces zijn leuk .

thanks for reply

Jij ook .

[mbravenboer]

D2k: kan der zo 1-2-3 geen speld tussen krijgen

Hehe .

Voorlopig staat het dus nog op mijn lijstje voor een ' betere Java' . (Die je overigens heel goed zou kunnen schrijven als een front-end tot de huidige Java )

[Verwijderd]

Op donderdag 31 januari 2002 14:09 schreef mbravenboer het volgende:

Uitleg van een interface:

Hum das een beetje lastig.... Met een interface definieer je een soort type. Je geeft aan welke functionaliteit dit type heeft via methoden in de interface. Je implementeert deze methoden echter niet. Concrete klassen moeten namelijk deze interface implementeren. Je kunt zo een hele verzameling implementaties via dezelfde interface gebruiken, en dat is stoer .

Het zijn dus niet gewoon Classes?!

[mbravenboer]

Maentor: Het zijn dus niet gewoon Classes?!

Nee, maar een variable kan wel van het type van een interface zijn. Interfaces zijn beschrijvingen waaraan klassen kunnen voldoen. Ze eindingen daarom ook vaak op "able". Bijvoorbeeld: Cloneable, Runnable, Comparable etc... .

[Rhythmic]

Toch nog even een kritisch nootje dan

Als je maar een paar interfaces aan elkaar wilt plakken op die manier zie ik er wel heil in (het Runnable&Stoppable voorbeeld). Maar als ik iets wil hebben dat zowel Runnable, Stoppable, Suspendable, Cloneable als Comparable is dan lijkt het me niet echt overzichtelijk code opleveren als je methodes krijgt als

code:

void doIets(Runnable&Stoppable&Suspendable&Cloneable&Comparable r) {
   ...
}

Oftewel: in plaats van een interface-explosie heb je dan een type-naam explosie. Een RSI-bevorderence ontwikkeling

[mbravenboer]

Rhythmic: Toch nog even een kritisch nootje dan

Hehe . Je hebt hier natuurlijk wel een beetje gelijk in. Je krijgt inderdaad langere namen, maar het gaat mij ook niet zozeer om het aangeven van veel interfaces, maar meer om het maken van combinaties van interfaces zonder dat je daarvoor een nieuwe interface hoeft te maken die beide andere interface extend .

Het komt maar zelden voor dat je meer dan twee atomaire interfaces wilt samenstellen en dan zou je nu waarschijnlijk een samentrekking van die namen gebruiken als je de interfaces samenvoegt tot 1 interface.

[tomato]

Ik heb met interesse deze thread gelezen en vind het een mooi idee

Maar ik ben een beetje bang dat het luiheid is die hier om vraagt. Is het niet zo dat dit je uit kan nodigen minder goed OO design te maken?

Wanneer je verlangt van een object dat het aan twee interfaces voldoet zou het dus logisch zijn voor dit type object om aan deze interfaces te voldoen? En als dat dan zo voor de hand ligt zou je het type imho sowieso deze twee interfaces moeten laten implementeren. Is er een reden naast luiheid om dit te laten?

[mbravenboer]

tomato: Maar ik ben een beetje bang dat het luiheid is die hier om vraagt. Is het niet zo dat dit je uit kan nodigen minder goed OO design te maken?

Nee, ik denk het niet. Sterker nog: het nodigt uit tot beter design .

Wanneer je verlangt van een object dat het aan twee interfaces voldoet zou het dus logisch zijn voor dit type object om aan deze interfaces te voldoen?

Inderdaad. Dat moet enigszins logisch zijn. Dat wil echter niet zeggen dat het logisch genoeg is om daar ook een nieuwe interface voor te definieren . En daar ligt precies het punt waarop dit een gunstig idee is.

Ook voorkomt het dat je interfaces te veel methoden geeft, deze neiging zie je erg vaak voorkomen. Met de mogelijkheid om interfaces snel te combineren zal je denk ik eerder kiezen voor compacte interfaces die geen optionele functionaliteit bevatten. Optionele functionaliteit in interfaces vind ik namelijk zeer matig (en ja, dit kom je op veel plekken tegen in de Java API's).

En als dat dan zo voor de hand ligt zou je het type imho sowieso deze twee interfaces moeten laten implementeren. Is er een reden naast luiheid om dit te laten?

Nou ik denk dat je me nu verkeerd begrijpt: de klasse van het object dat gebruikt gaat worden via een variabele met als type een gecomineerde parameter moet nog steeds de interfaces implementeren. Je hoeft echter geen aparte interface te maken als je het object via een bepaalde combinatie van interfaces wilt gebruiken.

Voorbeeld:

code:

interface Suspendable
interface Resumable

class Blaat implements Suspendable, Resumable extends Boeh

Suspendable&Resumable x = new Blaat();
doSomething(x);

public void doSomething(Suspendable&Resumable x)
{
  ....
}

Merk trouwens op dat je de multi-interface notatie ook zou kunnen gebruiken als implements synax

code:

class Blaat implements Suspendable&Resumable extends Boeh

[Tomatrix]

Op donderdag 31 januari 2002 17:47 schreef mbravenboer het volgende:

Optionele functionaliteit in interfaces vind ik namelijk zeer matig (en ja, dit kom je op veel plekken tegen in de Java API's).

de 'remove' method in java.util.Iterator, brrrrr....

[mbravenboer]

Tomatrix: de 'remove' method in java.util.Iterator, brrrrr....

Juistum .

[whoami]

Op donderdag 31 januari 2002 13:42 schreef mbravenboer het volgende:
Als je nu een methode wilt schrijven die een object vereist die Runnable en Stoppable is, moet je een nieuwe interface maken (sorry voor de onzinnge naam):

code:

public interface RunnableStoppable extends Runnable, Stoppable
{
}

Nu kan je dus opgeven dat je een RunnableStoppable wilt hebben.

Ik heb het topic nog niet volledig gelezen, enkel een deel uit uw eerste post (shame on me ), maar ik dacht dat je in Java geen multiple inheritance hebt? Of geldt dat enkel voor classes en niet voor Interfaces.

Ondertussen de thread doorlezen en al een antwoord gezien.

* whoami praat geen Java

[Verwijderd]

Dat is dus een voordeel van scripting: daar heb je dit probleem niet

[mbravenboer]

Doekman: Dat is dus een voordeel van scripting: daar heb je dit probleem niet

.

* mbravenboer gaat hier maar niet op in omdat het geintje was, maar ik kan het haast niet laten .

[corani]

Tja, je zou natuurlijk een pre-processor kunnen bouwen voor Java

Dan kun je schrijven in een soort van Java++ met extended syntax, en die zet je dan weer om in gewone Java-code..

[mbravenboer]

corani: Tja, je zou natuurlijk een pre-processor kunnen bouwen voor Java

Dat suggereerde ik inderdaad ook al ja.... Dat is een mooie en makkelijke oplossing . Ik loop hiermee al wel een tijdje in m'n hoofd (zou het dan geen Java++ noemen ) maar het heeft nog steeds geen prioriteit.... druk druk druk .

[drm]

mbravenboer: (zou het dan geen Java++ noemen )

Java#

[mbravenboer]

drm: Java#

Bedankt voor het meedenken

Wat dacht je van Semeru? (ga maar eens uitzoeken wat dat is ).

[Verwijderd]

Op vrijdag 01 februari 2002 10:17 schreef mbravenboer het volgende:

[..]

Bedankt voor het meedenken

Wat dacht je van Semeru? (ga maar eens uitzoeken wat dat is ).

http://volcano.und.nodak.edu/vwdocs/volc_images/southeast_asia/indonesia/semeru.html

[mbravenboer]

Zef heeft het gevonden

Mooie pic .

Het schijnt dus de hoogste berg van Java te zijn .
(voor zover ik weet)