Zou iemand mij kunnen uitleggen wat een abstracte klasse in Java is? Ik snap niet echt het nut van zo'n klasse.
Alvast bedankt,
Laatste berichten
-
00:49
Ervaringen met "herontdekkingen" 11
-
00:37
Rotatie van het heelal 24
-
21:28
hall effect in vloeistof gebruiken als stromingssensor 6
-
17:59
Gezocht: de/een naam voor een getallenrij met een cauchyrij als partieelsommenrij
-
17:28
Casus uit de praktijk: positief test THC 18
-
17 apr
speciale rel. theorie 4
-
17 apr
Vreemde stank in huis 11
-
17 apr
3 vragen over mijn rooskleurige r.berekening H2netGekoppeldeHBrflowbatterij.
-
17 apr
Interpretatie reactie-energie 3
-
17 apr
Logistic equation (Pierre Verhulst,Belgian Mathematician) 5
-
16 apr
vB 9
-
15 apr
Kunnen quantum Zonnecellen 190% quantum efficiënt zijn 1
-
15 apr
Python: sockets sluiten 4
-
14 apr
Een eenvoudige logische redenering waarom tijd niet kan bestaan 'daarbuiten' 6
-
14 apr
Hoe kun je op quantumwijze getallen vinden in een rij die kleiner zijn dan getal k 3
-
13 apr
Documentenverdwijnen uit onedrive 1
-
12 apr
Behoud van impulsmoment en energie 5
-
12 apr
INLOG STORING / TIPS 4
-
09 apr
[natuurkunde] systeemgrafen 1
-
05 apr
afbuiging licht rond zware objecten via grondbeginselen relativiteitstheorie 490
Nieuwsberichten
-
04 mar
Een nieuw soort magnetisme: altermagnetisme
-
31 okt
AI kan via stem diabetes vaststellen 11
-
21 okt
Einstein krijgt wéér gelijk 45
-
07 feb
witter dan wit 20
-
19 jun
irrigatie en de aardas
Abstracte klassen
-
- Berichten: 7.068
Re: Abstracte klassen
Stel je maakt een programma om je garage op te ruimen. In je garage staan fietsen en koelkasten. Voor deze twee objecten maak je klassen aan. Beide klassen hebben een methode om te berekenen of ze op een bepaalde plek in de garage passen. Bovendien houdt elke klasse bij wat het gewicht is van de fiets of koelkast waarbij deze hoort en heeft een methode om dit gewicht uit te lezen.
Nu kom je na enig nadenken tot de conclusie dat het je eigenlijk niet kan schelen of je met een fiets of een koelkast te maken hebt. Je wilt gewoon je garage opruimen en daarvoor hoef je alleen maar te weten of het object dat je hebt past op een bepaalde plek. Je besluit een algemene klasse te maken die een willekeurig object representeert en je maakt hier subklasses van voor een fiets en een koelkast. Zo kun je vrolijk met objecten werken zonder dat je hoeft te weten wat het object eigenlijk is.
Stel nu dat je deze object klasse NIET abstract maakt. Om met dit object om te kunnen gaan zonder te weten wat het eigenlijk is, zal ook dit object methodes moeten hebben voor de berekening of er plek is en wat het gewicht is. Je zal dus een implementatie moeten schrijven voor deze methodes. Dit is voor de gewichtsmethode geen probleem. Deze methode werkt voor alle soorten objecten hetzelfde. De plek-berekenmethode daarentegen is voor elk soort object uniek. Hij zal bij een algemeen object (de hoofdklasse) nooit zinnig gebruikt kunnen worden. Elke subklasse zal deze methode dan ook altijd overschrijven. Je hebt dus een methode geimplementeerd die nooit gebruikt gaat worden (valt eigenlijk wel mee, want je laat hem natuurlijk leeg, maar goed). Daarbij komt nog eens dat een algemeen object helemaal niet mag bestaan. Je kunt er niks zinnigs mee. Het is echter met een gewone klasse geen enkel probleem om toch algemene objecten te maken.
Op het moment dat we nu de klasse abstract maken, is het niet meer mogelijk om objecten te maken van deze klasse. Dit is mooi want we hadden net geconstateerd dat dit toch niet iets zinnigs opleverde. Als we nu de plek-berekenmethode ook abstract maken hoeven we hem niet meer te implementeren. Bovendien is het hierdoor verplicht geworden om in een subklasse deze methode te maken (dit is een verschil met een gewone klasse waarbij de subklasse de methode van zijn hoofdklasse kan gebruiken). Dit voorkomt dus dat iemand vergeet de methode te implementeren.
Ik hoop dat dit wat licht op de zaak doet schijnen...
Nu kom je na enig nadenken tot de conclusie dat het je eigenlijk niet kan schelen of je met een fiets of een koelkast te maken hebt. Je wilt gewoon je garage opruimen en daarvoor hoef je alleen maar te weten of het object dat je hebt past op een bepaalde plek. Je besluit een algemene klasse te maken die een willekeurig object representeert en je maakt hier subklasses van voor een fiets en een koelkast. Zo kun je vrolijk met objecten werken zonder dat je hoeft te weten wat het object eigenlijk is.
Stel nu dat je deze object klasse NIET abstract maakt. Om met dit object om te kunnen gaan zonder te weten wat het eigenlijk is, zal ook dit object methodes moeten hebben voor de berekening of er plek is en wat het gewicht is. Je zal dus een implementatie moeten schrijven voor deze methodes. Dit is voor de gewichtsmethode geen probleem. Deze methode werkt voor alle soorten objecten hetzelfde. De plek-berekenmethode daarentegen is voor elk soort object uniek. Hij zal bij een algemeen object (de hoofdklasse) nooit zinnig gebruikt kunnen worden. Elke subklasse zal deze methode dan ook altijd overschrijven. Je hebt dus een methode geimplementeerd die nooit gebruikt gaat worden (valt eigenlijk wel mee, want je laat hem natuurlijk leeg, maar goed). Daarbij komt nog eens dat een algemeen object helemaal niet mag bestaan. Je kunt er niks zinnigs mee. Het is echter met een gewone klasse geen enkel probleem om toch algemene objecten te maken.
Op het moment dat we nu de klasse abstract maken, is het niet meer mogelijk om objecten te maken van deze klasse. Dit is mooi want we hadden net geconstateerd dat dit toch niet iets zinnigs opleverde. Als we nu de plek-berekenmethode ook abstract maken hoeven we hem niet meer te implementeren. Bovendien is het hierdoor verplicht geworden om in een subklasse deze methode te maken (dit is een verschil met een gewone klasse waarbij de subklasse de methode van zijn hoofdklasse kan gebruiken). Dit voorkomt dus dat iemand vergeet de methode te implementeren.
Ik hoop dat dit wat licht op de zaak doet schijnen...
-
- Berichten: 355
Re: Abstracte klassen
Als k het goed voorheb bedoede je het volgende:
Je maakt eigenlijk een klasse die hoger in de hiërarchie staat. Deze bevat de 2 subklassen. Nu blijkt dat een methode, nl. de plek-berekenmethode niet zinvol is aangezien deze voor de twee subklasse verchillend is. Hierop wordt de klasse abstract gemaakt, wat blijkbaar wil zeggen dat er geen objecten kunnen aangemaakt worden van deze klassen. Dit is goed angezien de plek-berekenmethode voor de beide subklassen verschillend was. Nu maken we de plek-berekenmethode abstract waardoor we die plek-berekenmethode moeten declareren in beide subklassen (wat goed is, aangezien het een verschillende berekening is).
Volgens mij is dan het grote nut van zo'n abstracte klasse, het laatste wat je zei, nl. dat de subklasse de methode van zijn hoofdklasse niet kan gebruiken.
Heel hard bedankt voor je uitleg,
Je maakt eigenlijk een klasse die hoger in de hiërarchie staat. Deze bevat de 2 subklassen. Nu blijkt dat een methode, nl. de plek-berekenmethode niet zinvol is aangezien deze voor de twee subklasse verchillend is. Hierop wordt de klasse abstract gemaakt, wat blijkbaar wil zeggen dat er geen objecten kunnen aangemaakt worden van deze klassen. Dit is goed angezien de plek-berekenmethode voor de beide subklassen verschillend was. Nu maken we de plek-berekenmethode abstract waardoor we die plek-berekenmethode moeten declareren in beide subklassen (wat goed is, aangezien het een verschillende berekening is).
Volgens mij is dan het grote nut van zo'n abstracte klasse, het laatste wat je zei, nl. dat de subklasse de methode van zijn hoofdklasse niet kan gebruiken.
Heel hard bedankt voor je uitleg,
