Archief - Java vraagje

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Shift

Legacy Member
Overerving / Constructor

public class Persoon {
public Persoon(int i)
{
System.out.println("Persoon");
}
public static void main(String[] args)
{
Persoon p = new Student();
}
}
public class Student extends Persoon {
public Student()
{
System.out.println("Student”);
}
}

Waarom geeft dit een error ?

Shift

Legacy Member
Omdat de constructor van Persoon een meegeleverde waarde voor int i verwacht ?

Cycloon

Legacy Member
Nee, Persoon heeft geen default constructor meer. Je moet dus nog expliciet public Persoon() {} toevoegen.

forloRn_

Legacy Member
Ik wil nu niet nitpicken maar ik vind "ja, omdat Persoon een meegeleverde waarde voor i verwacht" juister. Je gaat niet gewoon blindelings constructors bijmaken, enkel omdat je compiler komt klagen eh. Je zult het Persoon-gedeelte van je object tenslotte toch op één of andere manier moeten initialiseren.

En als je dan toch een no-arg constructor toevoegt, zal je negen van de tien even verderop vaststellen dat je die i toch nodig hebt.

Shift

Legacy Member
Neen dit was een voorbeeld van in de les. Das expres zo gemaakt. Was even op het verkeerde spoort met die non-default constructor

Cycloon

Legacy Member
forloRn_ zei:
Ik wil nu niet nitpicken maar ik vind "ja, omdat Persoon een meegeleverde waarde voor i verwacht" juister. Je gaat niet gewoon blindelings constructors bijmaken, enkel omdat je compiler komt klagen eh. Je zult het Persoon-gedeelte van je object tenslotte toch op één of andere manier moeten initialiseren.

En als je dan toch een no-arg constructor toevoegt, zal je negen van de tien even verderop vaststellen dat je die i toch nodig hebt.

Het meest logische zou zijn dat hij vanuit de default constructor in persoon de persoon(int) aanroept met een default value.

En steeds een default constructor toevoegen is toch wel aan te raden (desnoods protected). Zo kunnen afgeleide klassen nog steeds een no-argument constructor aanmaken. In situaties waar je weet dat een no-argument constructor nooit zal gebruikt worden kan je dat uiteraard achterwege laten.

Shift

Legacy Member
Nog een vraagje. Ik werk met eclipse. Stel ik heb dit :

- Project A -> Package B -> Class C

- Project D -> Package E -> Classe F

Nu wil ik de klasse C aanspreken in F. Hoe doe ik dat ? Rechterklik op project D , properties, Java build Path en daar Proeject A aan toevoegen helpt niet echt.

Cycloon

Legacy Member
Je klassen staan niet public? (Eerste wilde gok hoor, ik werk niet met eclipse)

Shift

Legacy Member
Alle klasse staan public. Maar momenteel los ik het op door gewoon de klasse C te kopieren in package E :)

adrianhates

Legacy Member
moet je die package niet importen waar je zijn inhoud nodig hebt? :)
zoals bvb bij swing:

import javax.swing.*;

MilM

Legacy Member
Waarschijnlijk heeft hij geen Jar file, maar enkel een .class file

Afhankelijk van wat er in die klasse staat, zijn er twee methodes dus:
-) ofwel de klasse gewoon kopiëren (beste oplossing waarschijnlijk als de klasse niet echt op zich staat)
-) ofwel de klasses bundelen in een jar en toevoegen aan uw project. Dit lijkt mij de beste methode als je verwacht dat je die klasses in meerdere projecten kunt gebruiken (dus eerder hulpklasses die op zich staan en niet project specifiek zijn)

adrianhates zei:
moet je die package niet importen waar je zijn inhoud nodig hebt? :)
zoals bvb bij swing:

import javax.swing.*;

Ja, maar dat kun je automatisch doen en daarvoor moet de klasse eerst tot het project behoren/toevoegen. Het is dat laatste waar zijn vraag om draait.

forloRn_

Legacy Member
Cycloon zei:
En steeds een default constructor toevoegen is toch wel aan te raden (desnoods protected). Zo kunnen afgeleide klassen nog steeds een no-argument constructor aanmaken.

Kan je dat even verduidelijken? Het één sluit het ander toch niet uit?

Cycloon

Legacy Member
Als je basisklasse een constructor implementeert met 1 of meerdere argumenten zonder de default constructor expliciet te programmeren dan kunnen afgeleide klassen geen default constructor meer implementeren.

Emerxill

Legacy Member
Jawel, als je van slecht design houdt :D

Code:
public class Student extends Person {
	private static int i;
	
	private Student() {
		super(i);
	}
	
	public static Student createStudent(int i) {
		Student.i = i;
		return new Student();		
	}
}

Cycloon

Legacy Member
Maarja, dat is geen klasse met een constructor met 1 of meer argumenten. Al goed dat je zelf aangeeft dat het slecht design is :p. Als persoon echter geen default constructor heeft zoals in de OP dan werkt je implementatie zelf niet.

forloRn_

Legacy Member
Ik zie nog altijd je punt niet Cycloon. Ik heb hier een base met een constructor met één of meer argumenten zonder default constructor en een afgeleide met een default constructor en dat compileert hoor:
Code:
class Base {
	public Base(int i) {}
}

class Derived extends Base {
	public Derived() {
		super(123);
	}
}

Cycloon

Legacy Member
Default constructor is created only if there are no constructors. If you define any constructor for your class, no default constructor is automatically created.

Waarom jouw code compileert ben ik niet zeker eigenlijk. Maar wat in de quote staat is het standaard gedrag.

Mogelijks werkt het omdat je zelf expliciet een constructor van de basisklasse oproept. Als je die super call weglaat compileert het waarschijnlijk niet meer.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan