[Java] Overloaden van variabelen uit inferface?

[VyperX]

Hallo,

Het is voor mij weer een tijdje geleden dat ik me actief met Java heb bezig gehouden, maar ik had me voorgenomen om een chat/webcam progje voor mezelf te bouwen.
Op het moment heb ik dus twee aparte delen, server/client en losse client, die op zich werken.
Het updaten van de webcam gebeurd bij beiden in een aparte thread. Voor allebei heb ik dus nu een aparte implementatie/extensie van Thread geschreven, die eigenlijk precies hetzelfde doen.

Java:

 class SvUpdateThread extends Thread {
    private ChatServer myCS;
    ....
} 

en

Java:

class ClUpdateThread extends Thread {
    private ChatClient myCC;
    ....
} 

Nu wilde ik dit naar 1 thread omzetten door beiden een nieuwe interface te laten implementeren: ChatEntity, waarna er nog maar 1 type UpdateThread hoefde te zijn die deze zou bedienen.
De interface zoals ik deze nu heb is als volgt:

Java:

interface ChatEntity {
    public Image camImage = null;
    public TextField camIntervalField = null;
    public TextField camUrlField = null;
    public TextField blaat = null;
    public MediaTracker medTrack = null;
    
    public void repaint();
}

Echter, zodra ik nu een Thread op basis van deze interface wil laten werken, blijkt dat de variabelen niet zijn "overloaded" door de ChatServer/ChatClient.

Kan iemand mij vertellen hoe ik dit wel voor mekaar kan krijgen, of is dit niet mogelijk?


P.s. Sorry voor de lange post

[whoami]

Kan een interface variablen bevatten? Ik dacht dat je in een interface enkel de method-signatures kon opgeven. (Om het simpel te zeggen).

In .NET krijg je alleszins compiler errors als je fields (variabelen) in een interface wilt definieren.

[VyperX]

Mja... daar kwam ik dus ook achter.
Het kan geen variabelen bevatten, alleen constanten blijkbaar.
Is er geen manier om die toch te "overloaden" ?
Heb niet zo veel behoefte om daar allemaal aparte "get" functies voor te gaan schrijven... (Maar als het niet anders kan.)

[Verwijderd]

Waarom maak je niet gewoon get en set methods voor die variabelen, ben je meteen van je hele probleem af. Ik vraag me trouwens af of die interface hierboven legaal is... ik wist dat je public final velden kunt opnemen, maar gewoon public

[VyperX]

Euh... zoals ik zei, het is een tijd geleden dat ik voor het laatst met java bezig ben geweest...
Het compileert in ieder geval wel, onder Sun Java 1.3.1

Maar ik zal het inderdaad maar moeten gaan oplossen m.b.v. get-/set-methoden. Bedankt voor de hulp

[Soultaker]

Mooi voorbeeld waarin multiple inheritance van pas zou komen, trouwens.

Eigenlijk is het wel zo netjes om alle attributen toegankelijk te maken met get/set methoden, zodat er gecontroleerd kan worden op geldige invoer (zelfs al is dat niet altijd nodig), maar het is natuurlijk jammer dat je de implementatie daarvan elke keer opnieuw moet intypen, omdat je die simpelweg niet in je interface kwijt kunt.

[Glimi]

VyperX schreef op 19 november 2002 @ 14:40:
Mja... daar kwam ik dus ook achter.
Het kan geen variabelen bevatten, alleen constanten blijkbaar.
Is er geen manier om die toch te "overloaden" ?
Heb niet zo veel behoefte om daar allemaal aparte "get" functies voor te gaan schrijven... (Maar als het niet anders kan.)

Maak abstracte classes die de interface implementeren. Je schrijft dan de methodes die algemeen zijn in de abstracte class en de specefieke (verschillen) tussen de Threads. Zo heb je het gebaseerd op een interface en heb je de abstractie daarvan nog overeind staan

[Tuinhark]

wist dat je public final velden kunt opnemen, maar gewoon public

Wanneer je een veld opneemt in een interface, maakt hij er automagisch een private static final van. (Derhalve 'moet' je eigenlijk hoofdletters gebruiken in de naam.) Je mag al die 3 keywords dan ook weglaten, maar voor de leesbaarheid kun je ze er beter wel neerzetten.

[Glimi]

Tuinhark schreef op 19 november 2002 @ 15:58:
wist dat je public final velden kunt opnemen, maar gewoon public

Wanneer je een veld opneemt in een interface, maakt hij er automagisch een private static final van. (Derhalve 'moet' je eigenlijk hoofdletters gebruiken in de naam.) Je mag al die 3 keywords dan ook weglaten, maar voor de leesbaarheid kun je ze er beter wel neerzetten.

Puur gezien moet Java dit eigenlijk niet toelaten en gewoon een foutmelding opgooien als men zulke constructies maakt. Immers je probeert gewoon iets te doen, wat eigenlijk niet mag en het levert (zoals hierboven te zien is) gewoon dikke verwarring op

[VyperX]

Glimi schreef op 19 november 2002 @ 15:44:
[...]

Maak abstracte classes die de interface implementeren. Je schrijft dan de methodes die algemeen zijn in de abstracte class en de specefieke (verschillen) tussen de Threads. Zo heb je het gebaseerd op een interface en heb je de abstractie daarvan nog overeind staan

Hmmm... als ik het me goed herinner moest je abstracte classes toch "extenden" met je eigen classe? En kon een classe maar 1 andere classe extenden?
Dan lukt het ook niet meer, want ChatServer/ChatClient extenden beiden al "Frame".
(Ik weet het, het is geen nette opbouw wat dat betreft, maar goed... tis maar voor hobby )

[Glimi]

VyperX schreef op 19 november 2002 @ 16:42:
(Ik weet het, het is geen nette opbouw wat dat betreft, maar goed... tis maar voor hobby )

Niet netjes? Gewoon fout imho Je zit View en data te mixen Moet je echt goed voor oppassen