[java] klasse interface

[Verwijderd]

Voor de kenners is het waarschijnlijk een eenvoudige vraag maar wat is precies een java type interface? Het enige wat ik tot nu toe gevonden heb is dat het een methode is om multiple inheritence mee te realiseren.

Zoeken met google levert 1000000000000 resultaten over GUI's

[ Voor 7% gewijzigd door Verwijderd op 28-05-2004 10:53 ]

[whoami]

Een interface is een 'beschrijving', een 'contract' waaraan de 'interface' van je class moet aan voldoen.
De interface bepaald welke methods (en wat de signature van die methods moet zijn) die class minstens moet hebben.

Pak er anders eens een boek over OOP bij, daar staat er wel meer info over.

En anders moet je eens ff gerichter googlen

[ Voor 25% gewijzigd door whoami op 28-05-2004 10:55 ]

[Alarmnummer]

Verwijderd schreef op 28 mei 2004 @ 10:50:
Voor de kenners is het waarschijnlijk een eenvoudige vraag maar wat is precies een java type interface? Het enige wat ik tot nu toe gevonden heb is dat het een methode is om multiple inheritence mee te realiseren.

Zoeken met google levert 1000000000000 resultaten over GUI's

Java staat geen multiple inheritance toe, je kan dus niet zeggen:

class A extends B,C,D

Met een interface kan je dat wel doen:

class A implements B,C,D.

Je kan dus zoals je zegt multiple inheritance toevoegen.

Persoonlijk vind ik een interface veel belangrijker voor een ander doeleinde, namelijk je contract. In je interface beschrijf je het contract waar maker (van de implementatie van die interface) zich aan moet houden. En waar de gebruikmaker rekening mee moet houden. Op deze manier kan je dus implementatie en contract van elkaar scheiden (zoals je ziet bij headers files en c++).

Je moet daarom (als er geextend gaat worden) ontwerpen vanuit een interface en eventueel een abstract de convenience implementaties laten dragen. Je kan dan zelf kiezen of je van die abstract class wilt extenden (dus impliciet die interface extend), of zelf die interface gaat implementeren.

[whoami]

Alarmnummer schreef op 28 mei 2004 @ 10:58:
[...]

Op deze manier kan je dus implementatie en contract van elkaar scheiden (zoals je ziet bij headers files en c++).

Ik vind dat niet echt een goede vergelijking.
Het is natuurlijk wel waar dat je met een interface het 'contract' gescheiden houd, maar een header-file in C++ is niet hetzelfde als een interface imo.
In een header file bepaal je welke member methods en member-fields een bepaalde class heeft, terwijl de definitie van een interface niet 'gekoppeld' is aan een class. Een class kan wel een interface implementeren.

[Alarmnummer]

whoami schreef op 28 mei 2004 @ 11:07:
[...]

Ik vind dat niet echt een goede vergelijking.
Het is natuurlijk wel waar dat je met een interface het 'contract' gescheiden houd, maar een header-file in C++ is niet hetzelfde als een interface imo.
In een header file bepaal je welke member methods en member-fields een bepaalde class heeft, terwijl de definitie van een interface niet 'gekoppeld' is aan een class. Een class kan wel een interface implementeren.

Ik ben het helemaal met je eens.. althans.. tot een tijdje geleden. Waar dacht je dat: Encapsulation voor stond? Niemand hoeft te weten hoe een object aan de binnenkant eruit ziet, en je kan dus ook zo het een implementatie door een andere vervangen. Je kunt het dan wel niet dynamisch regelen zoals je dat met een interface kan, maar dat wil niet zeggen dat je niet kan wisselen

[whoami]

Alarmnummer schreef op 28 mei 2004 @ 11:12:
[...]

Ik ben het helemaal met je eens.. althans.. tot een tijdje geleden. Waar dacht je dat: Encapsulation voor stond? Niemand hoeft te weten hoe een object aan de binnenkant eruit ziet, en je kan dus ook zo het een implementatie door een andere vervangen. Je kunt het dan wel niet dynamisch regelen zoals je dat met een interface kan, maar dat wil niet zeggen dat je niet kan wisselen

Mjah, in een header file neem je dus ook de member-variablen op, en dat heeft toch IMHO niet echt iets met het 'contract' te maken, eerder al met implementatie.

Daarnaast is een header file 'gekoppeld' aan de implementatie van die specifieke class, en ik denk dus dat het nogal verwarrend kan overkomen als je zegt dat je een interface (zoals we die in Java / C# / ... kennen) kan vergelijken met een header-file in C++.

[Flax]

whoami schreef op 28 mei 2004 @ 10:54:
Een interface is een 'beschrijving', een 'contract' waaraan de 'interface' van je class moet aan voldoen.
De interface bepaald welke methods (en wat de signature van die methods moet zijn) die class minstens moet hebben.

IMHO is een interface als lapmiddel ingevoerd omdat je geen multiple inheritance hebt.

[Alarmnummer]

Flax schreef op 28 mei 2004 @ 11:32:
[...]

IMHO is een interface als lapmiddel ingevoerd omdat je geen multiple inheritance hebt.

Absoluut niet. Bij een interface heb je de garantie dat er geen implementatie aanwezig is en bij een class dus niet. Hierdoor kan je veel beter allerlei oo patterns erop los laten dan op classes. Dus interfaces zijn beter dan multiple inheritance.

[whoami]

Flax schreef op 28 mei 2004 @ 11:32:
[...]

IMHO is een interface als lapmiddel ingevoerd omdat je geen multiple inheritance hebt.

Nee, dat is het imo niet.

Multiple (implementation) inheritance heb je vrijwel niet nodig. Met een interface beschrijf je een contract waaraan een class moet aan voldoen.
Door met die interface te werken, kan je aan andere methods / classes zeggen aan welk 'contract' een argument dat je doorgeeft aan een method moet voldoen, zonder dat je hoeft te specifieren welk type class dat moet zijn.
(Dat kan je ook zonder interfaces doen, met een gewone 'base' class, maar met een interface ga je nog een stapje verder).

[curry684]

Verwijderd schreef op 28 mei 2004 @ 10:50:
Voor de kenners is het waarschijnlijk een eenvoudige vraag maar wat is precies een java type interface? Het enige wat ik tot nu toe gevonden heb is dat het een methode is om multiple inheritence mee te realiseren.

Zoeken met google levert 1000000000000 resultaten over GUI's

Sorry hoor, maar dit is echt een typische 'koop eens een boek' vraag. Hele basale OOP- en Java-kennis, die iedere tutorial je leert en die je met Google zoals whoami aangeeft zo moet kunnen vinden.

Ergo, dicht

[edit]

Hum laat voor deze keer maar open, whoami en Alarmnummer zijn wel lekker aan de ruzie

[ Voor 8% gewijzigd door curry684 op 28-05-2004 11:50 ]

[Flax]

Alarmnummer schreef op 28 mei 2004 @ 11:34:
[...]

Absoluut niet. Bij een interface heb je de garantie dat er geen implementatie aanwezig is en bij een class dus niet. Hierdoor kan je veel beter allerlei oo patterns erop los laten dan op classes. Dus interfaces zijn beter dan multiple inheritance.

Ik heb metopzet IMHO erbij gezet omdat ik weet dat mensen hier nogal gevoelig op kunnen reageren, en absoluut is wel errug zwaar

Ik ken genoeg voorbeelden waarbij je ipv een interface een abstracte classe zou willen gebruiken, al is het alleen maar omdat je dan niet hoeft te proxie-en of een variable v die interface X implementeerd en jij moet X ook implementeren, maar ook een class Y implementeren. Dit is de reden waarom ik het een lapmiddel vind(een abstracte classe behoeft toch ook geen code te bevatten, alleen maar definities)

Ik weet hoe het OO-en werkt en daarbij kom je java toch te vaak deze ongein tegen. Wil je het in de details weten, dan wil ik er best een docu over maken, maar ik ben nu aan het werruk

ps: hoe maak ik in java een linked list van integer waarden, en ga ik deze allemaal met 1 ophogen (ja alles is een classe)

[whoami]

Als interfaces in Java een lapmiddel zouden zijn voor MI, dan zou MS wel even wat dieper nagedacht hebben, en MI ook in .NET beschikbaar gemaakt hebben.

Ik denk dat je eens eea moet lezen over design patterns. Het boek 'Design Patterns Explained' is een goed boek om eea over de voordelen van interfaces te leren.
Als je een goed object-model opstelt, dan heb je IMHO geen multiple inheritance nodig.

[Alarmnummer]

Flax schreef op 28 mei 2004 @ 11:59:
[...]

Ik heb metopzet IMHO erbij gezet omdat ik weet dat mensen hier nogal gevoelig op kunnen reageren, en absoluut is wel errug zwaar

Ik heb een (te) grote voorraad 'absoluut'

Ik ken genoeg voorbeelden waarbij je ipv een interface een abstracte classe zou willen gebruiken, al is het alleen maar omdat je dan niet hoeft te proxie-en of een variable v die interface X implementeerd en jij moet X ook implementeren, maar ook een class Y implementeren. Dit is de reden waarom ik het een lapmiddel vind(een abstracte classe behoeft toch ook geen code te bevatten, alleen maar definities)

In veel gevallen zet ik eerst een interface op, en voor het gemak maak ik er dan ook een abstract class bij. Op deze manier heb ik de vrijheid van een interface maar het eventuele gemak van een abstract class. En als een abstract class geen code bevat, waarom maak je er dan geen interface van?

ps: hoe maak ik in java een linked list van integer waarden, en ga ik deze allemaal met 1 ophogen (ja alles is een classe)

Als je met een List moet werken, dan kun je het op de volgende manier doen:

code:

void incAll(List<Integer> intList){
    for(int k=0;k<intList.size();k++)
         intList.set(k,intList.get()+1);    
}

Maar ik ga er van uit dat je het als geintje bedoelt..

[ Voor 45% gewijzigd door Alarmnummer op 28-05-2004 12:16 ]

[Flax]

whoami schreef op 28 mei 2004 @ 12:08:
Als interfaces in Java een lapmiddel zouden zijn voor MI, dan zou MS wel even wat dieper nagedacht hebben, en MI ook in .NET beschikbaar gemaakt hebben.
[snip]
Als je een goed object-model opstelt, dan heb je IMHO geen multiple inheritance nodig.

half mee eens Ik blijf graag koppig


Maar wanneer je een project hebt, waar constant aan ontwikkeld wordt, is dit dus niet echt mogelijk.

Zullen we dit draadje maar stoppen? We komen toch niet op 1 lijn

[whoami]

Als je een project hebt waar constant aan ontwikkeld wordt (wat niet zo vreemd is), dan wil dat toch niet zeggen dat je niet meer over het design moet gaan nadenken, en je de bestaande code niet kunt refactoreren ?

_{En ik zie al helemaal niet in waarom dit draadje zou moeten gestopt worden}

[Verwijderd]

oke oke, duidelijk waar een interface voor is. Voldoende info tnx.

[Flax]

whoami schreef op 28 mei 2004 @ 12:25:
Als je een project hebt waar constant aan ontwikkeld wordt (wat niet zo vreemd is), dan wil dat toch niet zeggen dat je niet meer over het design moet gaan nadenken, en je de bestaande code niet kunt refactoreren ?

_{En ik zie al helemaal niet in waarom dit draadje zou moeten gestopt worden}

a- Je moet toch ook backwards compatible blijven, dus kan je niet altijd remodelleren
b- We denken er anders over en ik heb geen tijd om jou nu een voorbeeld te geven van het probleem van OO zonder multiple inheritance. Ik heb een baan en ik moet daar ook wat aan doen.
c- Waarom zou je alles opnieuw gaan modulleren, omdat je taal de tekortkoming heeft dat deze je wensen niet ondersteund. Je moet toch wel realiseren dat tijd geld is en dit soort dingen je teveel tijd kosten

[whoami]

Tijd is geld idd, en je kan idd niet blijven modelleren (paralysis by analysis), maar het ontbreken van MI is geen tekortkoming van een taal.

Interfaces zijn ook geen lapmiddel voor MI, want het doel van interfaces is eerder om een contract op te leggen aan een class.
Ik blijf er ook bij dat multiple implementation inheritance -mits je een goed OO design hebt- in 99% v/d gevallen niet nodig is.

[whoami]

Misschien kan je ook eens even dit artikel lezen.

[ Voor 25% gewijzigd door whoami op 28-05-2004 14:07 ]

[Robtimus]

Alarmnummer schreef op 28 mei 2004 @ 12:11:
Als je met een List moet werken, dan kun je het op de volgende manier doen:

code:

void incAll(List<Integer> intList){
    for(int k=0;k<intList.size();k++)
         intList.set(k,intList.get()+1);    
}

Maar ik ga er van uit dat je het als geintje bedoelt..

Ik hoop dat JIJ dit als geintje bedoelt. Deze vorm van itereren kan behoorlijk inefficient zijn als je bv een LinkedList gebruikt. De juiste manier voor een generieke manier is natuurlijk via de ListIterator:

Java:

void incAll(List<Integer> intList)
{
    for (ListIterator<Integer> it = intList.listIterator(); it.hasNext(); )
        it.set(it.next() + 1);
}

listIterator() levert in principe voor elke class de meest optimale implementatie.

_{(dat ListIterator<Integer> is maar gegokt hoor, ik ben nog niet bekend met de generics voor Java)
over die k vergeten in de intList.get() zal ik het maar niet hebben he?}

[Alarmnummer]

IceManX schreef op 28 mei 2004 @ 14:37:
[...]
Ik hoop dat JIJ dit als geintje bedoelt. Deze vorm van itereren kan behoorlijk inefficient zijn als je bv een LinkedList gebruikt. De juiste manier voor een generieke manier is natuurlijk via de ListIterator:

Java:

void incAll(List<Integer> intList)
{
    for (ListIterator<Integer> it = intList.listIterator(); it.hasNext(); )
        it.set(it.next() + 1);
}

listIterator() levert in principe voor elke class de meest optimale implementatie.

Check de code maar eens van de iterator voor de linkedlist. Die heeft er geen want hij maakt gebruik van de abstractlist zijn iterator en die werkt fijn met een index. Een linkedlist is dus altijd zo traag als de pest met itereren

_{over die k vergeten in de intList.get() zal ik het maar niet hebben he?}

Ik heb een speciale java compiler die dat aanpast

[Verwijderd]

oke, duidelijk, clear, done

[gorgi_19]

Verwijderd schreef op 28 mei 2004 @ 15:12:
oke, duidelijk, clear, done

Erhm, dat jouw probleem is opgelost, wil niet zeggen dat de discussie afgelopen is.

[Alarmnummer]

gorgi_19 schreef op 28 mei 2004 @ 15:34:
[...]

Erhm, dat jouw probleem is opgelost, wil niet zeggen dat de discussie afgelopen is.

M.a.w. je topic is gekaapt

[Robtimus]

Alarmnummer schreef op 28 mei 2004 @ 14:58:
Check de code maar eens van de iterator voor de linkedlist. Die heeft er geen want hij maakt gebruik van de abstractlist zijn iterator en die werkt fijn met een index. Een linkedlist is dus altijd zo traag als de pest met itereren

Niet juist. Het is even tracen, maar je komt er wel.

Java:

public class LinkedList extends AbstractSequentialList

LinkedList definieert geen iterator(), dus kijken in AbstractSequentialList:

Java:

public Iterator iterator() {
    return listIterator();
}

Noch AbstractSequentialList noch LinkedList definieert public ListIterator listIterator() of public iterator iterator(), dus kijken in AbstractList:

Java:

public ListIterator listIterator() {
    return listIterator(0);
}

In LinkedList:

Java:

public ListIterator listIterator(int index) {
    return new ListItr(index);
}

In de private ListItr van LinkedList:

Java:

private Entry lastReturned = header;
private Entry next;
private int nextIndex;
...
public boolean hasNext() {
    return nextIndex != size;
}

public Object next() {
    checkForComodification();
    if (nextIndex == size)
        throw new NoSuchElementException();

    lastReturned = next;
    next = next.next;
    nextIndex++;
    return lastReturned.element;
}

Ik zie daar toch echt een next.next staan, dus zonder index.

[whoami]

Even een subtiele kick o:

Programmeren naar interfaces zorgt er ook voor dat je een 'pluggable' systeem kunt maken.