🚀 go-pugleaf

"Passero" <bla@bla.bla> writes:

> Hetgeen ik eigenlijk zou willen is een interface waar ik attributen kan
> gebruiken maar wanneer je bij een interface een attribuut definieert is dat
> automatisch final en dat wil ik niet. Daarom had ik gedacht aan een
> abstracte klasse maar dan heb ik geen controle dat alle methode'n worden
> ge�mplementeerd.

Ik doe vaak een combinatie van die twee:

public interface IGateway
{
   public long getId();
   public void setId(long id);

   public void someBusinessLogic();
}

public abstract class AbstractGateway implements IGateway
{
   private long mId;

   public long getId()
   {
      return mId;
   }

   public void setId(long id)
   {
      mId = id;
   }
}

De abstract class neemt de interface over. Dus je zal de overige methods van de
interface nog meoten implementeren in de subclass van de abstract class. Dat is
toch de 'controle' die je zoekt?

   public class MyGateway extends AbstractGateway
   {
      public void someBusinessLogic()
      {
         ...
      }
   }

Wat je in de abstract class stopt hangt helemaal van je model af. Ik doe het
nu voornamelijk voor de properties.

 S.

"Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
news:m2k71n5ll1.fsf@tiSateh.local...

>
> Ik doe vaak een combinatie van die twee:
>
<knip>
>
> De abstract class neemt de interface over. Dus je zal de overige methods
van de
> interface nog meoten implementeren in de subclass van de abstract class.
Dat is
> toch de 'controle' die je zoekt?
>

Het probleem bij mij is dat ik verschillende klasse nodig heb die dezelfde
methode moeten gebruiken maar anders implementeren. Al de methode die ik
beschrijf in de interface moeten ook voorkomen in de klasse, dit wil zeggen
dat wanneer ik zo'n nieuwe klasse wil maken, ik eerst een abstracte klasse
moet maken die de implementatie doet en dan die eigenlijke klasse laten
erven van de abstracte, das toch beetje onhandig?
Ik zou ook al mijn attributen in alle klassen opnieuw kunnen defini�ren maar
dan zit ik met redundantie maar vraag me nu af of die hier nu zo erg zou
zijn. Dan kan ik wel gebruik maken van de interface en heb ik geen abstracte
klasse nodig en heb ik ook controle op de implementatie.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

Passero wrote:

> Hetgeen ik eigenlijk zou willen is een interface waar ik attributen kan
> gebruiken maar wanneer je bij een interface een attribuut definieert is dat
> automatisch final en dat wil ik niet. Daarom had ik gedacht aan een
> abstracte klasse maar dan heb ik geen controle dat alle methode'n worden
> ge�mplementeerd.

Is het niet zo dat elke abstracte method geimplementeerd moet worden?

-- 
John

Freelance Perl / Java developer available  -  Mail for more info

John Bokma <postmaster@castleamber.com> writes:

> Passero wrote:
> 
> > Hetgeen ik eigenlijk zou willen is een interface waar ik attributen kan
> > gebruiken maar wanneer je bij een interface een attribuut definieert is dat
> > automatisch final en dat wil ik niet. Daarom had ik gedacht aan een
> > abstracte klasse maar dan heb ik geen controle dat alle methode'n worden
> > ge�mplementeerd.
> 
> Is het niet zo dat elke abstracte method geimplementeerd moet worden?

Ja.

 S.

"Passero" <bla@bla.bla> writes:

> "Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
> news:m2k71n5ll1.fsf@tiSateh.local...
> 
> >
> > Ik doe vaak een combinatie van die twee:
> >
> <knip>
> >
> > De abstract class neemt de interface over. Dus je zal de overige methods
> van de
> > interface nog meoten implementeren in de subclass van de abstract class.
> Dat is
> > toch de 'controle' die je zoekt?
> >
> 
> Het probleem bij mij is dat ik verschillende klasse nodig heb die dezelfde
> methode moeten gebruiken maar anders implementeren. Al de methode die ik
> beschrijf in de interface moeten ook voorkomen in de klasse, dit wil zeggen
> dat wanneer ik zo'n nieuwe klasse wil maken, ik eerst een abstracte klasse
> moet maken die de implementatie doet en dan die eigenlijke klasse laten
> erven van de abstracte, das toch beetje onhandig?
> Ik zou ook al mijn attributen in alle klassen opnieuw kunnen defini�ren maar
> dan zit ik met redundantie maar vraag me nu af of die hier nu zo erg zou
> zijn. Dan kan ik wel gebruik maken van de interface en heb ik geen abstracte
> klasse nodig en heb ik ook controle op de implementatie.

Ik begrijp je probleem niet, of jij begrijpt mijn oplossing niet. Teken voor
de lol eens de hierarchie van die classes in een posting hier? Gewoon een
outline in ascii :)

 S.

> Daarom had ik gedacht aan een
> abstracte klasse maar dan heb ik geen controle dat alle methode'n worden
> ge�mplementeerd.

Als je een class een abstract class laat extenden, en die extended class 
is zelf niet abstract MOET je ALLE nog abstracte methods (zowel van de 
direct subclassed abstract class als van evt. 'hogere' abstract 
classes/interfaces) implementeren. Ziedaar je controle.

> Het gaat er hem om dat ik een interface/abstracte klasse wil maken waar ik
> definieer welke methoden ik heb voor het importeren van bestanden. In de
> klasse die de interface implementeerd of de abstracte klasse verlengd
> schrijf ik dan de effectieve broncode voor die methode. Wanneer ik een
> abstracte klasse gebruik ben ik niet zeker dat bij het maken van een andere
> klasse ook alle methoden worden ge�mplementeerd en dat is hier wel nodig dus
> als iemand een idee heeft of de gulden middenweg?

Dat is dus wel zo. Waar jij volgens mij bang voor bent is het scenario 
zoals je dat bijvoorbeeld bij Servlets aantreft; in HttpServlet is elke 
method al ge�mplementeerd met dummy inhoud. Als je in een subclass dan 
niet oplet sla je mogelijk methods over (want een override is nooit 
verplicht). Maar dat is hier dus niet aan de hand; een concrete class 
kan niet ��n abstract method meer hebben.

Volgens mij is een abstract class dus wel degelijk je oplossing. Het in 
een andere posting geschetste scenario waarbij een interface deels wordt 
ge�mplementeerd door een abstracte class, die vervolgens weer wordt 
extended door ��n of meerdere "eind"-subclasses, kom je veel tegen als 
alle "eind"-subclasses een aantal methods gezamenlijk kunnen gebruiken. 
Zulke methods (met name utilities, bestandsafhandeling, etc.) neem je 
dan als niet-abstract in de abstracte class op.

Hopelijk brengt dit je wat verder.

Groeten,
Joost van Stuijvenberg

"Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
news:m2u10rw5ok.fsf@tiSateh.local...
> John Bokma <postmaster@castleamber.com> writes:
>
> > Passero wrote:
> >
> > > Hetgeen ik eigenlijk zou willen is een interface waar ik attributen
kan
> > > gebruiken maar wanneer je bij een interface een attribuut definieert
is dat
> > > automatisch final en dat wil ik niet. Daarom had ik gedacht aan een
> > > abstracte klasse maar dan heb ik geen controle dat alle methode'n
worden
> > > ge�mplementeerd.
> >
> > Is het niet zo dat elke abstracte method geimplementeerd moet worden?
>
> Ja.
>
>  S.

Uh, is dat zo?
Wat is een abstracte methode? Een methode die geen implementatie heeft in de
class waarin hij is gedeclareerd. Dus had het antwoord ook "nee" mogen zijn
lijkt me...

>>>Is het niet zo dat elke abstracte method geimplementeerd moet worden?

>>Ja.
>> S.

> Uh, is dat zo?
> Wat is een abstracte methode? Een methode die geen implementatie heeft in de
> class waarin hij is gedeclareerd. Dus had het antwoord ook "nee" mogen zijn
> lijkt me...

Ik denk dat er bedoeld werd of het zo was dat elke abstracte method in 
de uiteindelijke concrete class ge�mplementeerd moet zijn. Een 
niet-abstracte class kan geen enkele abstracte method meer hebben.

Groeten,
Joost van Stuijvenberg

"Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
news:m2u10rw5ok.fsf@tiSateh.local...
> John Bokma <postmaster@castleamber.com> writes:

> >
> > Is het niet zo dat elke abstracte method geimplementeerd moet worden?
>
> Ja.
>

Elke methode die jeb eschrijft in een interface MOET ge�mplementeerd worden
maar een abstracte methode MAG ge�mplementeerd worden. Bij een interface kan
je geen attributen gebruiken tenzij het final zijn maar ik heb dus een
combinatie nodig: elke methode die ik beschrijf MOET ge�mplementeerd worden
en ik heb attributen nodig die niet final zijn.

>  S.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

> Elke methode die jeb eschrijft in een interface MOET ge�mplementeerd worden
> maar een abstracte methode MAG ge�mplementeerd worden.

Sorry, dat is onzin. Althans, als je uiteindelijk een bruikbare class 
(dus een concrete class) wilt opleveren. En omdat ik het gevoel heb dat 
je toch iets werkends wil opleveren zal je uiteindelijk op een concrete 
class uitkomen waarin ALLE nog niet ge�mplementeerde methods worden 
ge�mplementeerd.

Een interface is niets anders dan een 100% abstracte klasse.

Groeten,
Joost van Stuijvenberg

"Joost" <niet.versturen@email.bestaat.niet> schreef in bericht
news:4054d432$0$558$e4fe514c@news.xs4all.nl...
>
> Sorry, dat is onzin. Althans, als je uiteindelijk een bruikbare class
> (dus een concrete class) wilt opleveren. En omdat ik het gevoel heb dat
> je toch iets werkends wil opleveren zal je uiteindelijk op een concrete
> class uitkomen waarin ALLE nog niet ge�mplementeerde methods worden
> ge�mplementeerd.
>

Daar heb je 100% gelijk in maar zeg dat eens tegen onze docenten... Daar
zijn ze niet tevreden mee hoor. Het theoretisch gedeelte moet ook goed zijn
en als je dan afkomt met het argument dat je het toch moet implementeren
voor een goede werking, dat is niet goed. De ontwerper moet ervoor zorgen
dat diegene die implementeert die methode's zeker niet mag vergeten. Dat
zullen ze zeggen...


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

Passero wrote:
> Daar heb je 100% gelijk in maar zeg dat eens tegen onze docenten... Daar
> zijn ze niet tevreden mee hoor. Het theoretisch gedeelte moet ook goed zijn
> en als je dan afkomt met het argument dat je het toch moet implementeren
> voor een goede werking, dat is niet goed. De ontwerper moet ervoor zorgen
> dat diegene die implementeert die methode's zeker niet mag vergeten. Dat
> zullen ze zeggen...

IRC mag je in Java geen instanties van abstracte klassen aanmaken. Zodra 
je dus een instantie van een abstracte klasse tegenkomt, weet je 100% 
zeker dat alle methodes zijn geimplementeerd.

groente
-- Sander

On Mon, 15 Mar 2004 12:14:33 +0000, Passero wrote:

> "Joost" <niet.versturen@email.bestaat.niet> schreef in bericht
> news:4054d432$0$558$e4fe514c@news.xs4all.nl...
>>
>> Sorry, dat is onzin. Althans, als je uiteindelijk een bruikbare class
>> (dus een concrete class) wilt opleveren. En omdat ik het gevoel heb dat
>> je toch iets werkends wil opleveren zal je uiteindelijk op een concrete
>> class uitkomen waarin ALLE nog niet ge�mplementeerde methods worden
>> ge�mplementeerd.
> 
> Daar heb je 100% gelijk in maar zeg dat eens tegen onze docenten... Daar
> zijn ze niet tevreden mee hoor. Het theoretisch gedeelte moet ook goed zijn
> en als je dan afkomt met het argument dat je het toch moet implementeren
> voor een goede werking, dat is niet goed.

Niet enkel voor een goede werking, maar gewoon opdat het zou compileren.

> De ontwerper moet ervoor zorgen
> dat diegene die implementeert die methode's zeker niet mag vergeten. Dat
> zullen ze zeggen...

En hoe zou hij deze methode in het geval van een abstracte klasse wel
kunnen vergeten, en bij een interface niet?
De compiler geeft geeft zowel bij een interface als bij een abstracte
klasse een foutmelding indien de implementerende/uitbreidende klasse de
nodige methoden niet implementeren.

> ---
> Outgoing mail is certified Virus Free.

Dit is geen mail, en het moet '-- ' zijn (dus met spatie erachteraan).

-- 
Bruno

"You've got to have a gimmick if your band sucks."
		-- Gary Giddens

"Passero" <bla@bla.bla> writes:

> "Joost" <niet.versturen@email.bestaat.niet> schreef in bericht
> news:4054d432$0$558$e4fe514c@news.xs4all.nl...
> >
> > Sorry, dat is onzin. Althans, als je uiteindelijk een bruikbare class
> > (dus een concrete class) wilt opleveren. En omdat ik het gevoel heb dat
> > je toch iets werkends wil opleveren zal je uiteindelijk op een concrete
> > class uitkomen waarin ALLE nog niet ge�mplementeerde methods worden
> > ge�mplementeerd.
> >
> 
> Daar heb je 100% gelijk in maar zeg dat eens tegen onze docenten... Daar
> zijn ze niet tevreden mee hoor. Het theoretisch gedeelte moet ook goed zijn
> en als je dan afkomt met het argument dat je het toch moet implementeren
> voor een goede werking, dat is niet goed. De ontwerper moet ervoor zorgen
> dat diegene die implementeert die methode's zeker niet mag vergeten. Dat
> zullen ze zeggen...

Geef je docent eens een boek over Java, misschien helpt dat.

 S.

"Stefan Arentz" <stefan@tiSateh.local> schreef in bericht
news:m2ish6ozf8.fsf@tiSateh.local...
>
> Geef je docent eens een boek over Java, misschien helpt dat.
>

Ja das waar want veel verstand van java heeft hij niet en mijn docent java
niet veel verstand van OO. Die wil dan alle functionaliteit in de main van
een klasse schrijven en gewoon enkele methode schrijven. Bijna geen andere
klasse... Erg h� :d

>  S.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 28/02/2004

>>Sorry, dat is onzin. Althans, als je uiteindelijk een bruikbare class
>>(dus een concrete class) wilt opleveren. En omdat ik het gevoel heb dat
>>je toch iets werkends wil opleveren zal je uiteindelijk op een concrete
>>class uitkomen waarin ALLE nog niet ge�mplementeerde methods worden
>>ge�mplementeerd.

> Daar heb je 100% gelijk in maar zeg dat eens tegen onze docenten... Daar
> zijn ze niet tevreden mee hoor. Het theoretisch gedeelte moet ook goed zijn
> en als je dan afkomt met het argument dat je het toch moet implementeren
> voor een goede werking, dat is niet goed. De ontwerper moet ervoor zorgen
> dat diegene die implementeert die methode's zeker niet mag vergeten. Dat
> zullen ze zeggen...

Stop. Halt. Ademhalen. Pauze. Plasje doen. Beentjes strekken.... En daar 
gaan we weer.


OVER ABSTRACTE KLASSES:

Een abstracte klasse is een klasse met ��n of meerdere abstract methods 
(dit is overigens niet verplicht, nul abstract methods mag ook maar dan 
is het vrij zinloos om een klasse abstract te maken). Een abstracte 
klasse kan nooit, nooit, nooit worden ge�nstantieerd. Het is dus niet 
nodig om bang te zijn dat iemand jouw nog-in-de-steigers-staande klasse 
instantieert. Dingen vergeten kan dus niet. Om een klasse, die afgeleid 
is van een abstracte klasse of een interface (lees: een 100% abstracte 
klasse) te kunnen instantieeren is het noodzakelijk dat ALLE abstracte 
methods zijn ge�mplementeerd. Je kunt dit niet vergeten wat je krijgt 
van javac de compiler op je ... als je vergeet een abstracte method te 
implementeren. Nogmaals: niemand komt voorbij de compiler als je dit 
vergeet dus wees niet bang dat iemand een klasse 'half af' gebruikt. 
Alles dat maar enigszins nodig is voor de goede werking is dus aanwezig 
bij de uiteindelijke 'concrete' klasse.

OVER LERAREN:

Een leraar die van jou verwacht dat je een list verzint waardoor 
collega-programmeurs zaken niet kunnen vergeten is nogal parano�de 
bezig. Je kunt inderdaad de compiler gebruiken om deze check te doen 
maar uiteindelijk moet uit een test (zoek ook eens info over bijv. JUnit 
voor je leraren) blijken of je code goed werkt en je niets vergeten 
bent. Als je zo denkt moet je ook alle methods van je classes FINAL 
declareren, want o wee als er ooit toch eens een boze programmeur komt 
die jouw zorgvuldig gecomponeerde methods gaat overriden met allerlei 
lelijke en foute statements. Daarmee blokkeer je elk toekomstig 
hergebruik en je beschouwt jezelf als de beste programmeur ter wereld, 
want waarom zou iemand toch jouw code moeten overriden - die code is 
toch perfect, huh?!?

Bovendien: het feit dat je een method niet vergeet te implementeren zegt 
nog altijd niets over de kwaliteit van die method. Dus je blindstaren op 
de implementatie van methods is onzin.

Groeten, ook aan je leraren,

Joost van Stuijvenberg