[java] klassen en subklassen

[In physics I trust]

Hallo,

Ik zit met volgend probleem. Om het eenvoudig te houden, zal ik het uitleggen aan de hand van een voorbeeld: stel je voor dat ik klasse Dier heb, en drie subklassen ervan: Hond, Kat, Koe. Ik run een kinderboerderij, en elk jaar wil ik een nieuw dier aankopen. Dat bepaal ik met een random generator, dat lukt.

Ik heb een functie Loop(), die voor elk van de dieren anders is.

Hoe kan ik nu zeggen 'neem het nieuw aangekochte beest, en laat zijn functie Loop() erop los'?

Ik had in de betreffende klasse eerst een variabele Dier mijndier aangemaakt, en dan een functie Dier getMijnDier(), maar deze geeft dus een Dier terug, en niet het juiste soort Dier.

Abstract kan ik de klasse dier niet maken, omdat er andere methoden in zitten die dat niet toelaten.

Alvast bedankt!

[ZVdP]

In een abstracte klasse hoeven niet alle methoden abstract te zijn, of had je een andere belemmering bij het abstract maken van Dier?

[317070]

1) maak Dier abstract (zoals ZvdP aangaf)

2) maak ook een functie in Dier, die een error throwed als die aangeroepen wordt.

[EvilBro]

Hoe kan ik nu zeggen 'neem het nieuw aangekochte beest, en laat zijn functie Loop() erop los'?

Code: Selecteer alles

-- Test.java

public class Test {

public static void main(String[] args) {

Dier nieuwDier = geefEenDier();

nieuwDier.Loop();

}

public static Dier geefEenDier() {

return (new Konijn());

}

}

-- Dier.java

public class Dier {

public void Loop() {

System.out.println("Ik beweeg op onbekende manieren.");

}

}

-- Konijn.java

public class Konijn extends Dier {

public void Loop() {

System.out.println("Ik huppel alsof ik in het bos bent.");

}

}

Deze code print: "Ik huppel alsof ik in het bos bent." Een konijnobject mag aan een dierreferentie geknoopt worden omdat konijn een subklasse is van Dier. Tijdens het uitvoeren wordt dan de loop-functie van het dierobject gezocht en dat is de loop() van het konijnobject. Je kan dus met het nieuwe dier aan de wandel zonder dat je code hoeft te weten wat voor dier het nou eigenlijk is. Dit is het hele punt van dit soort code. Als je moet uitvinden wat voor soort beest het is dan is er iets mis.

maak ook een functie in Dier, die een error throwed als die aangeroepen wordt.

Ik weet niet wat je precies van plan bent, maar het klinkt alsof je het exception-systeem van java aan het misbruiken bent voor iets waarvoor het niet bedoeld is.

[In physics I trust]

Bedankt voor jullie reacties, nu heb ik het weer duidelijk voor ogen.

[317070]

Ik weet niet wat je precies van plan bent, maar het klinkt alsof je het exception-systeem van java aan het misbruiken bent voor iets waarvoor het niet bedoeld is.

Gja, dat is de ivoren-toren-theorie. In de praktijk heeft men in Java zelfs een exception voorzien speciaal voor zulke situaties:

public void loop(){

      throw new UnsupportedException();

}

Als het met abstract kan, zeker doen. Als het niet met abstract kan, dan is dit volgens mij de beste manier. Ik ga zeker niet ontkennen dat je je structuur kunt aanpassen zodat je het alsnog kunt fixen (ik heb het hier zelfs even geprobeerd), maar dat is veel slechter voor je code, naar mijn mening.

Noot: loop() moet met een kleine letter!!!

[Bart]

Waarom geen gebruik maken van interfaces?

[EvilBro]

Waarom geen gebruik maken van interfaces?

Dat kan, maar dat lijkt me conceptueel niet juist.

[317070]

Zoals je daar kunt lezen wordt er gezegd dat het handig is als je moet omgaan met keuzes uit het verleden. Dat is hier niet aan de orde.

I beg to differ, als ik dan oplossingen zie als:

Code: Selecteer alles

	public void Loop() {

System.out.println("Ik beweeg op onbekende manieren.");

}

en de equivalente nachtmerries

Code: Selecteer alles

	public void Loop() {

return;

}

public Object Loop() {

return null;

}

dan is dit volgens mij een one-way ticket richting een paar uur vrolijk debuggen. Als de functie niet verwacht wordt aangeroepen te worden, zorg dan dat ze niet bestaat. Als ze toch aangeroepen wordt omdat ze bestond om architecturale reden, dan is er iets mis en moet je een Exception throwen. Dan weet je in de toekomst meteen waar het probleem zit.

Interfaces lossen hier trouwens niets op, aangezien je dan Dier implements HeeftPoten hebt en dus niet verder bent gekomen.

[EvilBro]

I beg to differ, als ik dan oplossingen zie als:

Je verwart een voorbeeld om iets duidelijk te maken met een daadwerkelijke praktische situatie...

Als de functie niet verwacht wordt aangeroepen te worden, zorg dan dat ze niet bestaat.

Precies. En dat is dus precies waarom het gooien van een exception onzin is. Het is een symptoom van dat er iets mis is. Als je geen invloed hebt op de situatie, bijvoorbeeld omdat je werkt met al bestaande code, dan is het misschien een praktische oplossing. Als je die invloed wel hebt, bijvoorbeeld omdat je aan het ontwerpen bent, dan is het een slecht idee.

[Cycloon]

Dat je een exceptie throwt omdat een bepaalde method niet kan/mag aangeroepen worden in een bepaalde situatie is op zich niet zo fout in een service oriented design. Hier is daar uiteraard geen sprake van en kan het best vermeden worden. Anderzijds gaat het hier wel over overerving waar geen implementatie wordt overgeërfd, het valt dus zeker te overwegen om interfaces te gebruiken.