🚀 go-pugleaf

Passero wrote:
> IK heb een abstracte klasse die een aantal dingen doet en nu wil ik dat 
> de klassen die daarvan erven die methoden ook kunnen gebruiken maar als 
> ik ze public zet dan kunnen de andere klassen die ook gebruiken en dat 
> wil ik niet. Protected is ook geen oplossing want er zijn andere klassen 
> in het package die niet erven van die ene abstracte klasse.
> Is dit te doen in java of moet ik het via een omweg doen?
Tegen wie of wat moet je die klassen beschermen?

Groeten

Joost

Passero wrote:
> IK heb een abstracte klasse die een aantal dingen doet

Een abstracte klasse doet per definitie geen "dingen".

> en nu wil ik dat 
> de klassen die daarvan erven die methoden ook kunnen gebruiken maar als 
> ik ze public zet dan kunnen de andere klassen die ook gebruiken en dat 
> wil ik niet.

Methoden van een abstracte klasse kunnen niet worden aangeroepen.

> Protected is ook geen oplossing want er zijn andere klassen 
> in het package die niet erven van die ene abstracte klasse.
> Is dit te doen in java of moet ik het via een omweg doen?

Zo te horen wil je geen abstracte klasse, maar een gewone klasse. Alleen 
wil je niet dat je deze kunt instantieren.

Dat doe je niet door 'm abstract te maken. Er is een truuk om te zorgen 
dat je een klasse niet kunt instantieren: namelijk door de contructor 
private te maken.

Groeten,
Edwin Martin

-- 
http://www.bitstorm.org/

Edwin Martin schreef:

> 
> 
> Zo te horen wil je geen abstracte klasse, maar een gewone klasse. Alleen 
> wil je niet dat je deze kunt instantieren.
> 

Het zit eigenlijk zo: ik heb een aantal klassen die ongeveer hetzelfde 
doen. Ze moeten een interface hebben naar de buitenwereld toe. Dus een 
aantal methoden die MOETEN ge�mplementeerd worden. Dan zijn er nog een 
aantal methoden die door de abstracte klasse zijn ge�mplementeerd maar 
als ik die private zet, dan kunnen de klassen die erver ook niet meer 
aan die methoden en ze hebben die juist wel nodig. Het is de bedoeling 
dat enkel de klassen die erven van de abstracte klassen die methoden 
kunnen gebruiken. Het is dus niet echt public dat ze mogen zijn.

> Dat doe je niet door 'm abstract te maken. Er is een truuk om te zorgen 
> dat je een klasse niet kunt instantieren: namelijk door de contructor 
> private te maken.
> 
> Groeten,
> Edwin Martin
> 

"Edwin Martin" <e.j.martin@chello.nl> wrote in message
news:TsQJd.21247$PH1.15924@amsnews05.chello.com...
> Passero wrote:
> > IK heb een abstracte klasse die een aantal dingen doet
>
> Een abstracte klasse doet per definitie geen "dingen".
>
waarom zou je er dan maken?

> > en nu wil ik dat
> > de klassen die daarvan erven die methoden ook kunnen gebruiken maar als
> > ik ze public zet dan kunnen de andere klassen die ook gebruiken en dat
> > wil ik niet.
>
> Methoden van een abstracte klasse kunnen niet worden aangeroepen.

dus je kan geen methoden op een abstracte klasse zetten?

>
> > Protected is ook geen oplossing want er zijn andere klassen
> > in het package die niet erven van die ene abstracte klasse.
> > Is dit te doen in java of moet ik het via een omweg doen?
>
> Zo te horen wil je geen abstracte klasse, maar een gewone klasse. Alleen
> wil je niet dat je deze kunt instantieren.
>
> Dat doe je niet door 'm abstract te maken. Er is een truuk om te zorgen
> dat je een klasse niet kunt instantieren: namelijk door de contructor
> private te maken.

een andere goede truk is hem abstract te declareren. wedden dat je compiler
ook klaagt.
http://java.sun.com/docs/books/tutorial/java/javaOO/classdecl.html (kijk
even wat abstract betekent, is trouwens wel meer zo in class-based oop
talen)

nu vraag ik me toch wel af wat jij onder een abstracte klasse verstaat.

gC

"Passero" <bla@bla.bla> wrote in message
news:29PJd.5609$U95.109676@phobos.telenet-ops.be...
> IK heb een abstracte klasse die een aantal dingen doet en nu wil ik dat
> de klassen die daarvan erven die methoden ook kunnen gebruiken maar als
> ik ze public zet dan kunnen de andere klassen die ook gebruiken en dat
> wil ik niet. Protected is ook geen oplossing want er zijn andere klassen
> in het package die niet erven van die ene abstracte klasse.
> Is dit te doen in java of moet ik het via een omweg doen?

maak je package enkel voor de klassen die er wel aanmogen en gooi de andere
klassen in een andere package.
Toen ik nog met Java "werkte" was er zo iets als private protected,
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html, dat
dit deed (denk ik). Soit, nu is het niet meer mogelijk.

gC

Edwin Martin wrote:

> Passero wrote:
>> IK heb een abstracte klasse die een aantal dingen doet
> 
> Een abstracte klasse doet per definitie geen "dingen".

" Unlike interfaces, abstract classes may implement some of the methods.
Though you can't instantiate an abstract class, you can invoke its
static methods." http://mindprod.com/jgloss/abstractclass.html

Ik meen mij ook te herinneren dat een class met minstens 1 abstracte
method abstact was, dus dat abstract in de class signature (?) overbodig
is. 

Hmmm: http://java.about.com/cs/javadocumentation/g/abstractclass.htm

Mijn geheugen is zo slecht nog niet, lijkt het.

>> en nu wil ik dat 
>> de klassen die daarvan erven die methoden ook kunnen gebruiken maar
>> als ik ze public zet dan kunnen de andere klassen die ook gebruiken
>> en dat wil ik niet.
> 
> Methoden van een abstracte klasse kunnen niet worden aangeroepen.

Dus wel, zie boven.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Passero wrote:

> Edwin Martin schreef:
> 
>> Zo te horen wil je geen abstracte klasse, maar een gewone klasse.
>> Alleen wil je niet dat je deze kunt instantieren.
> 
> Het zit eigenlijk zo: ik heb een aantal klassen die ongeveer hetzelfde
> doen. Ze moeten een interface hebben naar de buitenwereld toe. Dus een
> aantal methoden die MOETEN ge�mplementeerd worden. Dan zijn er nog een
> aantal methoden die door de abstracte klasse zijn ge�mplementeerd maar
> als ik die private zet, dan kunnen de klassen die erver ook niet meer 
> aan die methoden en ze hebben die juist wel nodig. Het is de bedoeling
> dat enkel de klassen die erven van de abstracte klassen die methoden 
> kunnen gebruiken. Het is dus niet echt public dat ze mogen zijn.

protected class? (Ik gok maar wat :-D)

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Gerrit Cornelis wrote:

> Toen ik nog met Java "werkte" was er zo iets als private protected,
> http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html,
> dat dit deed (denk ik). Soit, nu is het niet meer mogelijk.

Omdat niemand het begreep :-D (of zoiets).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> Ik meen mij ook te herinneren dat een class met minstens 1 abstracte
> method abstact was, dus dat abstract in de class signature (?)
> overbodig is.

Een class met een abstracte methode _moet_ juist abstract in de class 
signature hebben staan.
Een class zonder abstracte methoden _mag_ abstract in de class signature 
hebben staan. Een class kan dus abstract zijn, zelfs al heeft deze geen 
abstracte methoden.

Groet, Jaap 

Gerrit Cornelis wrote:

> nu vraag ik me toch wel af wat jij onder een abstracte klasse verstaat.

Okee, ik dacht dat een abstracte klasse alleen abstracte methods kon 
bevatten.

Maar om de vermaarde Joshua Bloch te citeren: "Attempting to enforce 
noninstantiability by making a class abstract does not work."

De conclusie blijft dus dezelfde.

Edwin Martin.

-- 
http://www.bitstorm.org/

Passero wrote:

> Het zit eigenlijk zo: ik heb een aantal klassen die ongeveer hetzelfde 
> doen. Ze moeten een interface hebben naar de buitenwereld toe. Dus een 
> aantal methoden die MOETEN geïmplementeerd worden. Dan zijn er nog een 
> aantal methoden die door de abstracte klasse zijn geïmplementeerd maar 
> als ik die private zet, dan kunnen de klassen die erver ook niet meer 
> aan die methoden en ze hebben die juist wel nodig. Het is de bedoeling 
> dat enkel de klassen die erven van de abstracte klassen die methoden 
> kunnen gebruiken. Het is dus niet echt public dat ze mogen zijn.

Helaas kent Java geen modifier om methods alleen zichtbaar te laten zijn 
in de huidige klasse en afgeleide klassen (ik geloof dat protected dat 
in C++ doet).

Ik kan maar een oplossing bedenken:

public class F {
	private F() {
		// Kan geen instantie van deze klasse maken
	}
	public void bewerking_afgeschermd() {
		//...
	}
}

public class F1 extends F {
	public void bewerking() {
		//...
		// Gebruik bewerking_afgeschermd()
		super.bewerking_afgeschermd();
		//...
	}
	
	public void bewerking_afgeschermd() {
		throw new NoSuchMethodException();
	}
}

Groeten,
Edwin Martin


-- 
http://www.bitstorm.org/

Jaap Beetstra wrote:

> John Bokma wrote:
>> Ik meen mij ook te herinneren dat een class met minstens 1 abstracte
>> method abstact was, dus dat abstract in de class signature (?)
>> overbodig is.
> 
> Een class met een abstracte methode _moet_ juist abstract in de class 
> signature hebben staan.

Snap ik niet, zodra er 1 method abstract is, is het toch duidelijk dat de 
class alleen maar abstract kan zijn?

> Een class zonder abstracte methoden _mag_ abstract in de class signature 
> hebben staan.

Uiteraard, anders zou elke class abstract moeten zijn.

> Een class kan dus abstract zijn, zelfs al heeft deze geen 
> abstracte methoden.

En dat sluit niet uit dat een class met 1 abstracte method per definitie 
abstract is, en dus abstract overbodig is om te vermelden.

Maar een snelle test is het met je eens, als een method abstract is, moet 
je de class ook abstract maken.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

"Edwin Martin" <e.j.martin@chello.nl> wrote in message
news:jhUJd.9434$Pj6.1589@amsnews02.chello.com...
>

> Maar om de vermaarde Joshua Bloch te citeren: "Attempting to enforce
> noninstantiability by making a class abstract does not work."

enig idee waarom die mens dat beweerd? ik vind enkel de inhoudstabel van
zijn boek. de meeste andere puntjes in die tabel zijn redelijk voor de hand
liggend. Maar dit is en blijft een bizar statement aangezien er een speciale
taal construct voor voorzien is zou er geen reden mogen zijn om terug te
vallen op truc.

gC

John Bokma wrote:
> Jaap Beetstra wrote:

>> Een class met een abstracte methode _moet_ juist abstract in de class
>> signature hebben staan.
>
> Snap ik niet, zodra er 1 method abstract is, is het toch duidelijk
> dat de class alleen maar abstract kan zijn?

Ja, in zekere zin is het dubbele informatie dat je een class met abstracte 
methoden ook nog eens zelf declareert als abstract. Maar omdat een class 
zonder abstracte methoden ook abstract kan zijn, vind ik het wel consequent 
om (ook al is het afleidbaar) de class zelf ook als abstract te declareren.

>> Een class zonder abstracte methoden _mag_ abstract in de class
>> signature hebben staan.
>
> Uiteraard, anders zou elke class abstract moeten zijn.

Ik bedoel het omgekeerde, dat een class niet perse concreet is als deze geen 
abstracte (maar alleen concrete) methoden bevat.

Groet, Jaap 

Gerrit Cornelis wrote:

>>Maar om de vermaarde Joshua Bloch te citeren: "Attempting to enforce
>>noninstantiability by making a class abstract does not work."
> 
> enig idee waarom die mens dat beweerd? ik vind enkel de inhoudstabel van
> zijn boek. de meeste andere puntjes in die tabel zijn redelijk voor de hand
> liggend. Maar dit is en blijft een bizar statement aangezien er een speciale
> taal construct voor voorzien is zou er geen reden mogen zijn om terug te
> vallen op truc.

"The class can be subclassed and the subclass instantiated. Furthermore, 
  it misleads the user into thinking the class was designed for 
inheritance".

Edwin


-- 
http://www.bitstorm.org/

Edwin Martin <e.j.martin@chello.nl> writes:

> Gerrit Cornelis wrote:
> 
> >>Maar om de vermaarde Joshua Bloch te citeren: "Attempting to enforce
> >>noninstantiability by making a class abstract does not work."
> > enig idee waarom die mens dat beweerd? ik vind enkel de inhoudstabel
> > van
> > zijn boek. de meeste andere puntjes in die tabel zijn redelijk voor de hand
> > liggend. Maar dit is en blijft een bizar statement aangezien er een speciale
> > taal construct voor voorzien is zou er geen reden mogen zijn om terug te
> > vallen op truc.
> 
> "The class can be subclassed and the subclass
> instantiated. Furthermore, it misleads the user into thinking the
> class was designed for inheritance".

Wat een flauwekul. In Java, waar deze thread over gaat, is het maken van een
abstracte class een hele normale actie als je een componentn maakt dat 'net
niet af is'. Dus waarbij de subclass de missende functionaliteit moeten
implementeren.

Die abstracte class is ook helemaal niet te instantieren, zelfs niet na het
subclassen, de class blijft abstract en de compiler en runtime weten dat.

 S.

"Stefan Arentz" <stefan.arentz@gmail.com> wrote in message
news:87fz0lbl4q.fsf@keizer.soze.com...
> Edwin Martin <e.j.martin@chello.nl> writes:
>
> >
> > "The class can be subclassed and the subclass
> > instantiated. Furthermore, it misleads the user into thinking the
> > class was designed for inheritance".
>
> Wat een flauwekul. In Java, waar deze thread over gaat, is het maken van
een
> abstracte class een hele normale actie als je een componentn maakt dat
'net
> niet af is'. Dus waarbij de subclass de missende functionaliteit moeten
> implementeren.
>
> Die abstracte class is ook helemaal niet te instantieren, zelfs niet na
het
> subclassen, de class blijft abstract en de compiler en runtime weten dat.
>
Helemaal flauwekul is het niet. Joshua heeft blijkbaar een nood aan klassen
die niet gesubclassed mogen worden en die niet geinstantieerd mogen worden.
Dat zijn inderdaad geen abstracte klassen. Geen idee waarom iemand zulke
klassen zou willen (want eigenlijk val je dan gewoon terug op procedureel
programmeren) maar alla...de mens moet zijn boek met iets vullen natuurlijk.

gC

"Gerrit Cornelis" <gerrit_*remove*cornelis@belgacom.net> writes:

> "Stefan Arentz" <stefan.arentz@gmail.com> wrote in message
> news:87fz0lbl4q.fsf@keizer.soze.com...
> > Edwin Martin <e.j.martin@chello.nl> writes:
> >
> > >
> > > "The class can be subclassed and the subclass
> > > instantiated. Furthermore, it misleads the user into thinking the
> > > class was designed for inheritance".
> >
> > Wat een flauwekul. In Java, waar deze thread over gaat, is het maken van
> een
> > abstracte class een hele normale actie als je een componentn maakt dat
> 'net
> > niet af is'. Dus waarbij de subclass de missende functionaliteit moeten
> > implementeren.
> >
> > Die abstracte class is ook helemaal niet te instantieren, zelfs niet na
> het
> > subclassen, de class blijft abstract en de compiler en runtime weten dat.
> >
> Helemaal flauwekul is het niet. Joshua heeft blijkbaar een nood aan klassen
> die niet gesubclassed mogen worden en die niet geinstantieerd mogen worden.
> Dat zijn inderdaad geen abstracte klassen. Geen idee waarom iemand zulke
> klassen zou willen (want eigenlijk val je dan gewoon terug op procedureel
> programmeren) maar alla...de mens moet zijn boek met iets vullen natuurlijk.

Als je dat wil refactoren: een class die je niet mag instantieren en niet
subclassen die kan je zo uit je Java project donderden.

Wellicht is er een C++ reden, maar ik ken het boek en de auteur niet
heel goed. Ik hou me ook niet vast aan rare regeltjes waar academici
boeken mee vol schrijven moet ik bekennen.

 S.

Stefan Arentz wrote:
> "Gerrit Cornelis" <gerrit_*remove*cornelis@belgacom.net> writes:
[knip]
>>Helemaal flauwekul is het niet. Joshua heeft blijkbaar een nood aan klassen
>>die niet gesubclassed mogen worden en die niet geinstantieerd mogen worden.
>>Dat zijn inderdaad geen abstracte klassen. Geen idee waarom iemand zulke
>>klassen zou willen (want eigenlijk val je dan gewoon terug op procedureel
>>programmeren) maar alla...de mens moet zijn boek met iets vullen natuurlijk.
> 
> Als je dat wil refactoren: een class die je niet mag instantieren en niet
> subclassen die kan je zo uit je Java project donderden.

Niet te snel: Misschien zijn er static methoden?

Maar abstract methoden en niet-statics in zo'n klasse kunnen inderdaad
gewoon weggegooid worden. En als je dan een lege klasse overhoud kan
de klasse zelf natuurlijk ook weg.

> Wellicht is er een C++ reden, maar ik ken het boek en de auteur niet
> heel goed. Ik hou me ook niet vast aan rare regeltjes waar academici
> boeken mee vol schrijven moet ik bekennen.

Ik zou geen C++ reden kunnen verzinnen voor een abstracte klasse die
niet gesubclasst kan worden gebruikt. Helemaal al omdat C++ functies
buiten een klasse toestaat en dus geen Math-achtige classen hoeft
te definieren.

Misschien heeft de auteur over het hoofd gezien dat je door alle
constructors private te maken ook kunt voorkomen dat er ooit nog
een instantie van die klasse komt? Of denk ik nu weer te veel in C++
en kan er in Java wel om zo'n private heen worden geprogrammeerd?

Sjoerd

Sjoerd A. Schreuder wrote:

> Misschien heeft de auteur over het hoofd gezien dat je door alle
> constructors private te maken ook kunt voorkomen dat er ooit nog
> een instantie van die klasse komt? Of denk ik nu weer te veel in C++
> en kan er in Java wel om zo'n private heen worden geprogrammeerd?

Haha,

Dat is precies wat de auteur als oplossing geeft en waar ik mijn 
bijdrage aan deze draad mee begon.

Edwin Martin

-- 
http://www.bitstorm.org/

Stefan Arentz wrote:

>>"The class can be subclassed and the subclass
>>instantiated. Furthermore, it misleads the user into thinking the
>>class was designed for inheritance".
> 
> 
> Wat een flauwekul. In Java, waar deze thread over gaat, is het maken van een
> abstracte class een hele normale actie als je een componentn maakt dat 'net
> niet af is'. Dus waarbij de subclass de missende functionaliteit moeten
> implementeren.

Dit wordt ook helemaal niet ontkend.

> Die abstracte class is ook helemaal niet te instantieren, zelfs niet na het
> subclassen, de class blijft abstract en de compiler en runtime weten dat.

Hij heeft het duidelijk over het instantieren van een subklasse van een 
abstracte klasse.

Edwin Martin

-- 
http://www.bitstorm.org/