[Java] interface met static methods

[hobbit_be]

Hoi

simpel vraagje maar niets gevonden.

ik zou graag een interface hebben die een 'factory' moet zijn. nu is dta op zich
geen probleem maar ik hou alles graag netjes en zou de method dus static moeten zijn (anders is het geen factory) ie

Java:

public interface dkitIsFactory
{
    public static Object newInstance();
}

maar dit compileerd niet: dus moet die static weg wat dan weer wil zeggen
dat al mijn factories (zijn er al een stuk of 50 allemaal een non-static moeten doen. Nu goed die objecten worden dus slechts 1 keer gecreerd maar in theory kunnen er dus wel 2 worden gedaan...

iemand enig idee waarom dit niet werkt? of how ik zo'n 'strenge' rule kan opleggen...

[whoami]

in een interface mag je de access modifier niet meegeven dacht ik.
Of je het static keyword er nu wel of niet mag in meegeven weet ik niet. (Welke compile error krijg je trouwens?)

Verder vind ik niet dat een factory alleen maar static methods moet bevatten. Als je kijkt bv naar het Abstract Factory pattern, dan ga je toch ook echt een instance van die factory gaan maken. Op die manier kan je at runtime gaan bepalen welke factory je nu precies wilt maken.

Als je toch zowiezo een 'interface' wilt met enkel maar abstract methods, dan kan je toch ipv een interface een abstracte class gaan maken die de interface bepaalt.

[Alarmnummer]

hobbit_be schreef op 28 maart 2003 @ 17:42:
Hoi

simpel vraagje maar niets gevonden.

ik zou graag een interface hebben die een 'factory' moet zijn. nu is dta op zich
geen probleem maar ik hou alles graag netjes en zou de method dus static moeten zijn (anders is het geen factory) ie

Dat gaat idd niet werken

Je zou het als volgt kunnen oplossen:

Java:

interface FooFactoryInterface{
     public Foo create();
}

class FooFactory implements FooFactoryInterface{
     private static FooFactory s_instance;

     public static void createFooFactory(FooFactoryInterface f){
          if(s_instance!=null)
                 throw new RuntimeException("niet nog een keer he!");
          s_instance = new FooFactory(f);l
     }

      public FooFactory getInstance(){return s_instance;}

      private FooFactoryInterface _f;
   
      private FooFactory(FooFactoryInterface f){
             _f = f;
      }

       public void Foo create(){return _f.create();}
}

*is hier niet helemaal content mee*

[ Voor 13% gewijzigd door Alarmnummer op 28-03-2003 17:52 ]

[Glimi]

Interfaces kunnen geen static methods hebben.
Dit om de simpele reden dat een static method niet getransporteerd kan worden: een static method hoort bij een class en niet bij een instantie. Het is dan ook logisch dat bij overerven/implementeren statische methodes _NIET_ meegaan, omdat dan de link met de classe weg is! Daarom moet je ook altijd uitkijken met het maken van statische methodes, omdat deze niet te overriden zijn.

Zoals whoami al zegt zit je oplossing in het Abstract Factory pattroon van GoF. Laat een klasse fungeren als pure Factory voor dit soort objecten (en dus niet Factory method zoals jij hem bedoeld!). Succes ermee

[Alarmnummer]

Ik zie niet in waarom het niet bij een interface zou kunnen hoor En ik zie al helemaal niet in waarom je niet zou kunnen overriden. (Zal wel een technische reden hebben, maar logisch zou het niet uitmaken).

[whoami]

Alarmnummer schreef op 28 maart 2003 @ 17:54:
Ik zie niet in waarom het niet bij een interface zou kunnen hoor En ik zie al helemaal niet in waarom je niet zou kunnen overriden. (Zal wel een technische reden hebben, maar logisch zou het niet uitmaken).

hobbit_be wil in de interface vastleggen dat het om een static functie gaan.
(of bedoel je dat niet? )

[Soultaker]

Ik ben ook wel eens tegen deze beperking aangelopen en ik vind het wel jammer dat dit niet kan. In mijn geval gebruikte ik de reflection API om een klasse te verkrijgen; eigenlijk wilde ik checken of deze klasse bepaalde statische methoden implementeerde, maar dat kon dus niet door te controleren of de klasse een bepaalde interface ondersteund.

Ik vind het jammer dat het in Java niet mogelijk is om statische methoden te definiëren in een interface, maar ik zie wel in dat het niet binnen de rest van de Java wereld past. Als Java klassen first-class objecten zouden zijn (bijvoorbeeld afgeleiden van een Class object en covariant met hun instanties) zou het waarschijnlijk een stuk zinniger zijn om statische methoden toe te staan, aangezien je dan ook gewoon klassen als argumenten kunt meegeven (nu kun je uitsluitend een Class object meegeven, wat een algemeen type is voor alle denkbare klassen).

Ik vind de oplossing met de Abstract Factory trouwens ook maar matig. Hij werkt op een vieze manier om het feitelijke probleem heen: een singleton (eventueel zelfs zonder attributen) is feitelijk hetzelfde als een klasse met uitsluitend statische methoden, behalve dat zo'n instantie wel een degelijk gedefinieert type heeft en zo'n klasse niet. Het is in deze vorm dus een constructie om om de beperking zoals die in Java bestaat heen te werken. Het werkt in de praktijk prima, maar theoretisch gezien is het niet ideaal.

[ Voor 23% gewijzigd door Soultaker op 28-03-2003 18:04 ]

[Alarmnummer]

whoami schreef op 28 March 2003 @ 17:58:

[...]


hobbit_be wil in de interface vastleggen dat het om een static functie gaan.
(of bedoel je dat niet? )

Dat bedoel ik wel. En ik zie niet in waarom het bij een interface niet zou kunnen.

*begint beetje misselijk te worden van zijn pak pannekoeken*

[whoami]

Alarmnummer schreef op 28 March 2003 @ 18:00:
[...]


Dat bedoel ik wel. En ik zie niet in waarom het bij een interface niet zou kunnen.

Je kan toch niet in je interface vastleggen dat een method static moet zijn?

*begint beetje misselijk te worden van zijn pak pannekoeken*

[Alarmnummer]

whoami schreef op 28 maart 2003 @ 18:02:
Je kan toch niet in je interface vastleggen dat een method static moet zijn?

Nee, maar ik zie niet in waarom dit niet zo kunnen. Het zal wel een technische reden hebben, maar ik zie niet in waarom een statische methode zo ander behandeld moet worden dan een instantie methode.

Ik snap dat je zo nu en dan rare situaties kan krijgen:

Java:

class Persoon{
     static void blaat(println("persoon"););
}

class Slager extends Persoon{
     static void blaat(println("slager"));
}

En je doet nu Persoon.blaat dat je dan persoon op je scherm krijgt, en bij Slager.blaat slager, maar er zijn ook situaties waarin het op dezelfde manier handig kan zijn als het normale overriden van een methode.

Java:

class Persoon{
     static void blaat(println("persoon"););

      void afdrukken(){
            blaat();
      }
}

class Slager extends Persoon{
     static void blaat(println("slager"));
}

Nu krijg je bij Persoon, persoon en bij Slager slager. Niets mis mee toch?

[ Voor 18% gewijzigd door Alarmnummer op 28-03-2003 18:08 ]

[Glimi]

Alarmnummer schreef op 28 March 2003 @ 17:54:
Ik zie niet in waarom het niet bij een interface zou kunnen hoor En ik zie al helemaal niet in waarom je niet zou kunnen overriden.

Ik zie jouw logische verband niet helemaal. Als iets bij een klasse hoort, wat static imho betekend, kan ik het niet in verband brengen met een sub-klasse. Dat is toch echt een andere klasse hoor, in mijn beleving. Ik zal nog eens docs gaan nazoeken daarover Want we willen immers allemaal weten wat de beleving is van Sun

(Zal wel een technische reden hebben, maar logisch zou het niet uitmaken).

Dat ook wel een beetje Static members en functies worden bewaard in de 'static' adressspace, welke samen met de variabelen op de stack worden gebruikt om te tracen naar live objects in de heap.

[whoami]

Misschien schept dit wat duidelijkheid.

[Alarmnummer]

Glimi schreef op 28 March 2003 @ 18:08:
[nohtml]
[...]
Ik zie jouw logische verband niet helemaal. Als iets bij een klasse hoort, wat static imho betekend, kan ik het niet in verband brengen met een sub-klasse. Dat is toch echt een andere klasse hoor, in mijn beleving.

Ik denk dat we een groot verschil hebben ertussen. Ik vind het horen bij een 'class' een beetje vreemd. Ik denk liever in instantie en instantieloos.

Dat ook wel een beetje Static members en functies worden bewaard in de 'static' adressspace, welke samen met de variabelen op de stack worden gebruikt om te tracen naar live objects in de heap.

Hoe ze het hebben geimplementeerd interesseerd me niet zoveel. Ik vind mijn aanpak logischer. Ik zie niet in waarom een instantieloze methode ineens zo anders moet zijn dan een instantie methode. Dat is nergens voor nodig.

[Soultaker]

Alarmnummer schreef op 28 March 2003 @ 18:06:
Nee, maar ik zie niet in waarom dit niet zo kunnen. Het zal wel een technische reden hebben, maar ik zie niet in waarom een statische methode zo ander behandeld moet worden dan een instantie methode.

Het kan niet, omdat statische methoden (de naam zegt het al) statisch gebonden worden. Als je een statische methode dus op een interface definieert, zou je de methode in de interface zelf moeten implementeren en dat kan natuurlijk niet (het is slechts een interface).

[ Voor 8% gewijzigd door Soultaker op 28-03-2003 18:14 ]

[Soultaker]

whoami schreef op 28 March 2003 @ 18:10:
Misschien schept dit wat duidelijkheid.

Kijk, dat zij ik dus maar precies.

Alarmnummer schreef op 28 March 2003 @ 18:13:
Hoe ze het hebben geimplementeerd interesseerd me niet zoveel. Ik vind mijn aanpak logischer. Ik zie niet in waarom een instantieloze methode ineens zo anders moet zijn dan een instantie methode. Dat is nergens voor nodig.

Ik ben met je eens dat het gek is, maar zoals gezegd, past het niet binnen de rest van het ontwerp. Er zouden gelijk een heleboel dingen anders moeten.

[ Voor 51% gewijzigd door Soultaker op 28-03-2003 18:17 ]

[Alarmnummer]

Soultaker schreef op 28 March 2003 @ 18:13:
[...]

Het kan niet, omdat statische methoden (de naam zegt het al) statisch gebonden worden. Als je een statische methode dus op een interface definieert, zou je de methode in de interface zelf moeten implementeren en dat kan natuurlijk niet (het is slechts een interface).

Misschien is het woord static dan niet zo handig gekozen.

code:

interface Persoon{
    instantieloos void printBeroep();
}

class Slager implements Persoon{
   instantieloos void printBeroep(){println("slager");}
}

class Timmerman implements Persoon{
    instantieloos void printBeroep(){println("timmerman");)
}

Slager.printBeroep();

Ik ben met je eens dat het gek is, maar zoals gezegd, past het niet binnen de rest van het ontwerp. Er zouden gelijk een heleboel dingen anders moeten.

*is gezonde nederlander.. klaagt altijd*

[ Voor 17% gewijzigd door Alarmnummer op 28-03-2003 18:19 ]

[Soultaker]

Alarmnummer schreef op 28 March 2003 @ 18:17:
Misschien is het woord static dan niet zo handig gekozen.

Het woord past bij de implementatie. Een betere implementatie zou waarschijnlijk een andere naam dragen.

code:

interface Persoon{
    instantieloos void printBeroep();
}

class Slager implements Persoon{
   instantieloos void printBeroep(){println("slager");}
}

class Timmerman implements Persoon{
    instantieloos void printBeroep(){println("timmerman");)
}

Slager.printBeroep();

Deze code illustreert het probleem niet echt; het gaat hier om:

Java:

void functie(Persoon x)
{
    // Wat gebeurt er nu???
    x.printBeroep();
}

Met statische binding is dit niet op te lossen; daar heb je dus echt dynamische binding voor nodig (net zoals bij 'gewone' methoden het geval is).

[Alarmnummer]

Soultaker schreef op 28 maart 2003 @ 18:21:
[...]

Het woord past bij de implementatie. Een betere implementatie zou waarschijnlijk een andere naam dragen.


[...]

Deze code illustreert het probleem niet echt

Dit zou misschien beter zijn geweest:
Persoon p = new Slager();
p.printBeroep()

en dan krijg je slager op het scherm.

binding voor nodig (net zoals bij 'gewone' methoden het geval is).

Daarom wil ik die statische binding ook overboord gooien en het verschil tussen een statische en niet statische methode volledig laten vervallen.

[mbravenboer]

static methoden zouden in een aparte klasse moeten: de SlagerClass . Slager moet een klasse zijn waarbij de instanties van de klasse SlagerClass zijn. Static methoden zouden dus in de klasse beschrijving moeten, niet in de instantie beschrijving. Je kan dan ook met interfaces voor klassen gaan werken ...

[hobbit_be]

bloody hell - zoveel replys (ofwel was ik effe in de 'zone' ).. hmm nooit gedacht dat dit zo'n discussie zou loslaten ... wel jammer maar ik snap ook wel waarom Misschien zouden ze in Java 1.5 een nieuwe 'interface' moeten toelaten als een soort 'contract' (die dus nog lager dan interface staat) maar wat ik wel erg jammer vind is dat je dan ook niet de functie 'overwrite' met een static ervoor. Nou goed...

[Alarmnummer]

Ik denk dat ze verstandiger eraan doen om eerst eens te maken wat ze beloven. En niet met allerlei nieuwe beloftes komen die ze niet of zeer laat nakomen.

En ze moeten niet zozeel aandacht geven aan allerlei j2ee zaken, maar ze moeten eerst eens proberen om java aan de desktop kant proberen te verbeteren. Ik als javahova, weiger java gui programma`s te draaien (afgezien van Codeguide),

[ Voor 44% gewijzigd door Alarmnummer op 28-03-2003 18:59 ]

[hobbit_be]

SWT ?

[Soultaker]

hobbit_be schreef op 28 March 2003 @ 19:56:
SWT ?

Wat??

[Postman]

SWT: Standard Widget Toolkit (een of ander iets van IBM )

[MisterData]

Je kunt toch een abstracte class maken? Die mogen wel static methods hebben

[Soultaker]

MisterData schreef op 28 March 2003 @ 20:22:
Je kunt toch een abstracte class maken? Die mogen wel static methods hebben

Mja, maar dan kun je je afgeleide klasse niet meer ergens anders van afleiden (ten behoeve van de implementatie). Daarbij ben ik een groot voorstander van een klassehiërarchie die conceptueel logisch in elkaar zit en niet simpelweg bepaald wordt doordat het 'handig' is om code hier en daar te herbruiken. Wanneer een klasse geen specifieke variant van een andere klasse is, dan hoor je daar eigenlijk geen overerving voor te gebruiken (het Java keyword is daarom ook 'extends' en niet 'uses' of iets dergelijks).

FlamerX schreef op 28 March 2003 @ 20:15:
SWT: Standard Widget Toolkit (een of ander iets van IBM )

Maar wat heeft dat met het onderwerp te maken

[ Voor 57% gewijzigd door Soultaker op 28-03-2003 20:55 ]

[whoami]

Soultaker schreef op 28 maart 2003 @ 20:51:


Maar wat heeft dat met het onderwerp te maken

Dat was een reactie op een van Alarmnummer's posts, waarin hij zegt dat hij weigert een Java programma te draaien op de desktop vanwege de traagheid van de GUI.

[Alarmnummer]

Maar laten we daar niet verder over doormelken Laten we (redelijk) ontopic blijven (en jaja.. ik weet het.. ik begon, maar als ik in de sloot sping, dan springen jullie er toch niet achter aan? )

[hobbit_be]

Lemming zijnde alleen van een klif aub. ALs we zelfmoord plegen doen we dat liever met een beetje drama. Sloot bah..

Damn weer off-topic...

[whoami]

Soultaker schreef op 28 maart 2003 @ 20:51:
[...]

Mja, maar dan kun je je afgeleide klasse niet meer ergens anders van afleiden (ten behoeve van de implementatie).

Idd, maar ik denk dat dit toch de enige oplossing is als je wilt vastleggen dat die methods static moeten zijn.

Daarbij ben ik een groot voorstander van een klassehiërarchie die conceptueel logisch in elkaar zit en niet simpelweg bepaald wordt doordat het 'handig' is om code hier en daar te herbruiken. Wanneer een klasse geen specifieke variant van een andere klasse is, dan hoor je daar eigenlijk geen overerving voor te gebruiken (het Java keyword is daarom ook 'extends' en niet 'uses' of iets dergelijks).

Maareh, om nog even terug de gaan naar de topicstarter: waarom moet een factory volgens jou enkel uit static methods bestaan? Ik bedoel, een factory object kan even goed een instance-object zijn hoor.

[hobbit_be]

tja dat hangt natuurlijk af van je idee is van een factory - aangezien een factory steeds dezelfde dingen 'manufactured' lijkt het me tamelijk onlogisch om er meerdere van te hebben aangezien ze hetzelfde doen. (niet zoals de echte wereld waardoor je hogere productiviteit krijgt ofzo). In feite is een factory (imho) een singleton (class) die liefst niet geinstancieert moet worden (hence static) en waar iedereen 'aan kan'. Bij C++ heb je de keuze natuurlijk niet en moet je wel tenminste 1x de classe instantieren (je factories moeten wel OO zijn dus geen global func ofzo maar aangezien die static wel mooi vond op methods wou ik dus een Design By Contract toepassen en zo alle factories. Maar zoals als de hele discussie is een interface meer dan een contract... echt 'erg' is het niet maar het knaagt wel een beetje... hebben jullie PHP5 al bekeken - net java (ben ik eens benieuwt(d?) naar snelheid). Wanneer komt C++ + uit (ben de volledige naam vergeten)

[whoami]

hobbit_be schreef op 29 March 2003 @ 13:07:
tja dat hangt natuurlijk af van je idee is van een factory - aangezien een factory steeds dezelfde dingen 'manufactured' lijkt het me tamelijk onlogisch om er meerdere van te hebben aangezien ze hetzelfde doen. (niet zoals de echte wereld waardoor je hogere productiviteit krijgt ofzo). In feite is een factory (imho) een singleton (class) die liefst niet geinstancieert moet worden (hence static) en waar iedereen 'aan kan'.

Maar wat als je verschillende factories hebt en je moet at runtime bepalen welke factory je nu echt nodig hebt.... Ik bedoel, kijk eens naar het abstract factory pattern.

Bij C++ heb je de keuze natuurlijk niet en moet je wel tenminste 1x de classe instantieren

Hoezo? In C++ heb je toch ook static methods?

Wanneer komt C++ + uit (ben de volledige naam vergeten)

C++ is al lang uit hoor.

[Alarmnummer]

hobbit_be schreef op 29 maart 2003 @ 13:07:
Wanneer komt C++ + uit (ben de volledige naam vergeten)

C++ +? Je bedoelt zeker (c++)++

Kijk eens naar de volgende reeks:

++
++

Dit kan je ook kleiner schrijven als : # en dat geeft c# (c sjarp) en dat is al uit

[ Voor 4% gewijzigd door Alarmnummer op 29-03-2003 13:39 ]

[hobbit_be]

ik bedoelde wel degelijk de 'officiele' opvolger van C++ niet C#.

[alienfruit]

D++ ? hehe. Maar goed statisch methodes is zoiets class methods in Delphi? Die dingen kun je namelijk aanroepen als je nog geen instantie van de klasse hebt.

[Soultaker]

hobbit_be schreef op 29 maart 2003 @ 17:00:
ik bedoelde wel degelijk de 'officiele' opvolger van C++ niet C#.

D? Het zit wel leuk in elkaar, maar volgens mij wordt het nergens gebruikt.