[Java] static en interfaces

[Verwijderd]

hallo ik heb een vraagje, ik wou de volgende interface maken:

Java:

public interface StaticView {


    public static void paint( Graphics g, GameObjectModel model );


}

Omdat het me niet zinvol lijkt om meerder instanties te maken van een klasse die deze interface implementeerd. Alleen mag dit niet. Wie weet een mooi alternatief?

[Alarmnummer]

static erven helaas niet zo mee als niet static methodes

Je zou ook een enkele instantie kunnen aanmaken van en die kunnen meegeven aan iedereen die het nodig heeft. Een enkele instantie zal het probleem niet zijn Dat is de manier van werken die ik erg vaak gebruik.

[ Voor 11% gewijzigd door Alarmnummer op 04-06-2005 15:42 ]

[Verwijderd]

Ja ik snap het, maar omdat ik het netjes wou maken, d8 ik dat het beter was om het verplicht static te maken. Zodat andere mensen die deze api zouden gebruiken verplicht worden. Het moet namelijk makkelijk kunnen worden uitgebreidt met nieuwe typen views.

[ Voor 19% gewijzigd door Verwijderd op 04-06-2005 15:55 ]

[Alarmnummer]

Verwijderd schreef op zaterdag 04 juni 2005 @ 15:44:
Ja ik snap het, maar omdat ik het netjes wou maken, d8 ik dat het beter was om het verplicht static te maken.

Ik kan me er iets bij voorstellen, maar helaas.

Een instantie heeft trouwens ook wel voordelen. Als jij besluit om sturende parameters aan een implementatie van deStaticView mee te geven (bevoorbeeld een kleur die gebruikt moet worden bij het painten), dan kan dat met een instantie eenvoudiger. Als je ook een static field zou gebruiken om deze kleur in op te slaan, dan is het uitgesloten dat je meer dan 1 verschillende StaticViews kunt aanmaken. Nu hou je ruimte.

[edit]
Dit is trouwens ook meteen de reden dat strategies (een functie verpakt in een object) veel krachtiger zijn dan hogere orde functies (functies die functies als argumenten accepteren)

Het moet namelijk makkelijk kunnen worden uitgebreidt met nieuwe typen views.

Dat is met een interface zonder static methodes ook eenvoudig hoor

[ Voor 24% gewijzigd door Alarmnummer op 04-06-2005 16:02 ]

[BestTested!]

Verwijderd schreef op zaterdag 04 juni 2005 @ 15:33:
...Omdat het me niet zinvol lijkt om meerder instanties te maken van een klasse die deze interface implementeerd. Alleen mag dit niet. Wie weet een mooi alternatief?

Implementeer je klassen anders als Singletons. Op die manier kan je er maar 1 instantie van hebben.

[Alarmnummer]

BestTested! schreef op zaterdag 04 juni 2005 @ 16:13:
[...]
Implementeer je klassen anders als Singletons. Op die manier kan je er maar 1 instantie van hebben.

Singletons zijn evil En verder.. hoe wou je een systeem gaan maken dat eenvoudig van implementatie kan wisselen. Ik ben gek op patterns en goed ontwerp, maar kan me niet heugen dat ik het afgelopen jaar ook maar 1 singleton heb geimplementeerd. Singletons zijn bad... IOC is goed (Alle dependencies , dus ook dit soort Views, injecteer ik in de objecten die het nodig zijn).

[ Voor 9% gewijzigd door Alarmnummer op 04-06-2005 16:15 ]

[Verwijderd]

ik heb het nu zo, wat vind je ervan?

Java:

public class BlockPainter implements StaticView, ModelAndStaticViewConnector {

    private static final DefaultBlockView DEFAULTBLOCK = new DefaultBlockView();
    private static final DoubleBlockView  DOUBLEBLOCK  = new DoubleBlockView();
    private static final LargerBlockView  LARGERBLOCK  = new LargerBlockView();

   
    //methode van de StaticView
    public void paint(Graphics g, GameObjectModel model) {
        StaticView staticview = getView( model );
        staticview.paint( g, model );
    }

    //methode van de ModelAndStaticViewConnector
    public StaticView getView( GameObjectModel model ) {
        if( model      instanceof DefaultBlock )   return DEFAULTBLOCK;
        else if( model instanceof DoubleBlock )    return DOUBLEBLOCK;
        else if( model instanceof LargerBlock )    return LARGERBLOCK;
        else
            throw new IllegalArgumentException("De klasse " + model.getClass() + " van het model wordt niet ondersteund door deze painter");
    }


}

Java:

class DefaultBlockView implements StaticView {
    
    public void paint( Graphics g, GameObjectModel model ) {
            g.setColor( Color.RED );
            g.fillRect( model.getX(), model.getY(), model.getWidth(), model.getHeight() );
            g.setColor( Color.blue );
            g.fillRect( model.getX()+2, model.getY()+2, model.getWidth()-4, model.getHeight()-4 );
    }

}

[ Voor 17% gewijzigd door Verwijderd op 04-06-2005 16:18 ]

[Alarmnummer]

Verwijderd schreef op zaterdag 04 juni 2005 @ 16:17:
ik heb het nu zo, wat vind je ervan?

Ik weet verder niets van je ontwerp dus ik weet ook niet hoe nuttig/onnuttig het volgende is wat ik ga zeggen.

Je kunt nu niet eenvoudig een nieuwe Model in je systeem introduceren, want er zullen objecten zijn (zoals deze blockpainter) die runtime eruit knallen omdat ze een niet afgehandeld model tegenkomen. (Compiletime kan je 0.0 afdwingen met jouw oplossing)

Wat is het probleem om te vragen aan het model van:

model.getView()?

Dan kan je het netjes met polymorfisme oplossen. Het nadeel aan deze oplossing is dat er een dependency naar de view vanuit de model gaat ontstaan (dus minder eenvoudig om er ff een andere view over te jassen).

Je zou eventueel met een visitor wel typesafe dit probleem op kunnen lossen, maar visitors heb ik ook al lange tijd niet meer gebruikt. Ik kies ook nog regelmatig voor jouw oplossing.. webapplicaties zitten toch al stampvol met runtime-exceptions, kan er ook nog wel eentje bij

[ Voor 85% gewijzigd door Alarmnummer op 04-06-2005 16:27 ]

[Eelke Spaak]

Alarmnummer schreef op zaterdag 04 juni 2005 @ 15:58:
[...]

[edit]
Dit is trouwens ook meteen de reden dat strategies (een functie verpakt in een object) veel krachtiger zijn dan hogere orde functies (functies die functies als argumenten accepteren)

offtopic:
Dit wil ik toch even bestrijden . Functionele talen als LISP/Scheme zijn compleet, juist doordat ze functies als equivalent aan een expressie of variabele beschouwen (om precies te zijn, als een lambda-expressie).

[Alarmnummer]

Eelke Spaak schreef op zaterdag 04 juni 2005 @ 17:17:
[...]


[ot]Dit wil ik toch even bestrijden

Dat mag

Functionele talen als LISP/Scheme zijn compleet, juist doordat ze functies als equivalent aan een expressie of variabele beschouwen (om precies te zijn, als een lambda-expressie).[/ot]

Yep.. maar dat neemt nog steeds niet weg dat een Strategy krachtiger is dan een functie. Bij een strategy kan je state meenemen tussen de calls, en bij een strategy kan je state meenemen dat voor alle calls zo is. Uiteraard kan je wel met partieel parametrisatie, functies al gedeeltelijk voorzien van informatie, maar hoeveel standaard talen ondersteunen dit? Hogere orde functies zie je nog wel eens terug in mainstreamtalen, maar verder ook niet.

Daarom blijf ik bij mijn stelling dat strategies krachtiger zijn dan functies (binnen mainstream talen, want in de niet mainstreamtalen heb ik weinig praktische kennis.. alleen wat theoretische)

[edit]
Echte functionele talen kunnen trouwens ook veel beter closures bepalen dan talen zoals Java. Je zou ook nog state kunnen definieren in functie waarin je de functie aanmaakt. Helaas kan java dit vrij slecht (vandaar dat geklunger met die finals). Dus ook al zou java hogere orde functies ondersteunen, het zou minder krachtig zijn dan bij een echt functionele taal omdat je minder eenvoudig state mee kan nemen.

[ Voor 40% gewijzigd door Alarmnummer op 04-06-2005 18:40 ]