[Java] Constructors vastleggen in Interfaces?

[Verwijderd]

Kan iemand mij uitleggen waarom het niet mogelijk is om de signatuur van constructoren vast te leggen in een interface of desnoods in een abstracte klasse?
Klinkt misschien vaag, dus ik zal het even toelichten met een voorbeeldje:

Java:

public interface Picture {
    public BufferedImage getImage();
    public double getDifference(Picture p);
    public boolean getUsed();
    public void setUsed(boolean used);
    public void scalePicture(int bx, int by);
    public String toString();
    public Picture read(BufferedReader bRead) throws IOException;
}

Constructor vastleggen in de interface kan niet; als ik bijvoorbeeld "public Picture(File file);" toevoeg aan de interface kan ik deze niet implementeren door "public <naam klasse die interface implementeert>(File file) { ... }".

De functionaliteit waar ik naar op zoek ben is de volgende:
Een aantal implementaties van de interface moet in het programma gebruikt kunnen worden. De gebruiker kiest zelf welke hij wil gebruiken. Nu wil ik het onderliggende programma zo min mogelijk aanpassen en garanderen dat de constructoren die aangeroepen worden altijd bestaan. Dat lukt me dus niet met een interface en ook NIET met een abstracte constructor in een abstracte klasse die de interface implementeert (zie hieronder).

Java:

public abstract class AbstractPicture implements Picture {
    public abstract AbstractPicture(File file);
}

hoe kan ik toch op een nette manier garanderen dat het onderliggende programma altijd een bestaande constructor aanroept? en wat is de logica achter het niet kunnen vastleggen van constructoren in een interface?

[Verwijderd]

Verwijderd schreef op 16 februari 2003 @ 12:11:
Nu wil ik het onderliggende programma zo min mogelijk aanpassen en garanderen dat de constructoren die aangeroepen worden altijd bestaan. Dat lukt me dus niet met een interface en ook NIET met een abstracte constructor in een abstracte klasse die de interface implementeert (zie hieronder).

Bij mijn weten kan dat niet en is dat ook niet nuttig over het algemeen. Jij hebt het over het handmatig aanpassen van een programma en dan zeker weten dat er een constructor bestaat met die param list? Klinkt niet echt als een fijne aanpak (ik weet niet precies waarom je het wilt). Je kunt toch nooit een interface instantieren, dus waarom zou je dan de constructor willen vastleggen? Met methode aanroepen is dat nuttig, want dan is de instantie er al, maar het maken ervan gaat toch altijd via de niet abstracte klasse. En hoe die constructor er dan uit ziet, ja ach, dat maakt niet uit.

[whoami]

Tja, de naam van de constructor is altijd == de naam van de klasse. Aangezien een interface door meerdere klasses kan geimplementeerd worden, lijkt het me logisch dat het dan niet mogelijk is. Je kunt toch moeilijk al de naam van de constructor gaan vastleggen?
Als je het louter over het aantal en het type v/d parameters hebt v/d constructor, dan zou dat eigenlijk impliceren dat de interface op de een of andere manier reeds kan weten welke data-members je in de klasses zult hebben die die interface implementeren.

Een interface dient ervoor dat je kunt zeggen: deze klasse heeft die functionaliteit, want ze implementeert die interface. Een constructor heeft hier niets mee te zien imho.

Als je echter je classes extend van een abstracte class, dan kan je de constructors van die abstract class toch overriden in je inherited classes

[ Voor 6% gewijzigd door whoami op 16-02-2003 12:31 ]

[Diotoir]

Je zou lege constructors kunnen gebruiken en init() methodes. Die kan je wel in je interface defineren

dus:

Java:

Interface blah = new Class();
blah.init(parameters);

[ Voor 13% gewijzigd door Diotoir op 16-02-2003 12:19 ]

[Verwijderd]

Bedankt voor de reacties,

Zef: Waarom ik het precies wil is, omdat ik wil dat mijn onderliggende programma altijd een bestaande constructor aanroept op de klasse die die interface implementeert. Oftewel: Al die klasses moeten een aantal vastgelegde constructoren hebben.

whoami: Mij lukt het niet om een abstracte constructor te maken in een abstracte klasse zoals ik in mijn bericht al schreef. Begrijp ik uit jouw reactie dat dit wel mogelijk is? (hoe? )

Diotoir: Das psies de functionaliteit die ik nodig heb, maar ik hoop dat het ook kan zonder m'n constructoren aan te passen.

[whoami]

Verwijderd schreef op 16 February 2003 @ 12:28:
whoami: Mij lukt het niet om een abstracte constructor te maken in een abstracte klasse zoals ik in mijn bericht al schreef. Begrijp ik uit jouw reactie dat dit wel mogelijk is? (hoe? )

Neen, het is niet mogelijk.
Ik heb ff m'n post wat verduidelijkt.

Uit jouw reactie maakte ik eigenlijk op dat het mogelijk zou zijn, maar dat vond ik vreemd. Ik heb het echter niet specifiek getest, en ik ging er toen maar van uit dat jij dat wel gedaan had, en dat het mogelijk was. Ik heb het nu echter ook eens getest, en het is idd niet mogelijk.

[ Voor 33% gewijzigd door whoami op 16-02-2003 12:33 ]

[Glimi]

Wat dacht je van het maken van een 'Factory Method' pattern

Je maakt een feitelijk class die je PictureClasses contrueert en aanbied en dus de constructor ervan wrapt. Even wat voorbeeldcode

Java:

public interface PictureCreator {
        
        public Picture createPicture( /* our needed arguments here */ );
}

public abstract class AbstractPictureCreator implements PictureCreator {
        
        public Picture newPicture( ) {
                
                Picture p = createPicture( /* args */ );
                return p;
        }
        
        public Picture openPicture( ) {
                
                Picture p = createPicture( /* args */ );
                p.open( );
        }
}

public class OneConcretePictureCreator extends AbstractPictureCreator {

        public Picture createPicture( ) {
                
                return new Picture( Certain args, Noted here );
        }
}

public class OtherConcretePictureCreator extends AbstractPictureCreator {
        
        public Picture createPicture( ) {
                
                return new Picture( Other args, Noted here );
        }
}

Je wrapt je Pictures dus door PictureCreators, waarbij elke keer de implementatie van createPicture anders is Je spreekt dus alleen Picture constructor aan dmv een PictureCreator.

Echter omdat jij bezig bent met Pictures, welke veel subclasses zullen hebben (GIF Picture, JPEG Picture ed ) kun je dit gedrag misschien beter bundelen in een class.
Dit is ook een bekend pattroon nl. AbstractFactory. Zoek daar maar eens op @ google.

PS. Ik heb dit ff snel gedaan, GoF boek er niet bij gehad, dus het kan hier en daar was scheef zitten

[Verwijderd]

whoa, dank je, ziet er netjes uit ... ik ga er eens mee spelen