[JAVA/J2ME] Vraagje m.b.t. netheid van code

[Wijnbo]

Hallo, ik heb een vraagje over wat netjes is m.b.t. het volgende :

Interface "Item" (kan een bestand zijn, map, etc.)
Abstracte klasse "LocalItem" (Item op een telefoon)
Abstracte klasse "RemoteItem" (Item op een server)

In Item is delete(); gedefineerd, en in instanties van LocalItem ( o.a. LocalFile, Localfolder) etc is die methode geimplementeerd.


Vraag:

Moet of is het netjes als ik die methode nu ook implementeren in de abstracte klasse? En zo ja, wat is dan normaal? Een exception gooien? Lege methode?

Alvast bedankt!

[Ansur]

Als je in je abstracte klasse geen info hebt om daadwerkelijk die delete() te implementeren, kan je die best niet definiëren daar.

Mocht je wat basisgegevens hebben, kan je wel bv. al een gedeelte van de logica implementeren, en in je abstracte klasse enkele abstracte functies definiëren (en aanroepen) die je dan in de instanties uitwerkt (om de logica te vervolledigen)


Methode leeg laten is gevaarlijk: je kan dan vergeten om voor een bepaalde implementor een uitwerking te voorzien.

Een exception gooien is eigenlijk ook niet goed: als je gewoonweg die delete() functie niet definieert in je abstracte klasse, en ze vergeet te implementeren in één van je implementors, zal je een compilatiefout krijgen. Zo weet je ineens dat je nog iets vergeten bent.

[voodooless]

Als je een abstracte klasse hebt hebt betekend dat meestal dat je meerder implementaties hebt van deze. Als delete in al die implementaties hetzelfde is, dan kun je hem in de abstracte klasse definiëren. Heb je niet meerdere implementaties moet je je afvragen waarom je überhaupt een abstracte klasse hebt gemaakt, en als niet alle implementaties kunnen deleten kun je beter een losse Deletable interface maken met de delete methode. Dan kun je simpel met een instanceof checken of je wel of niet kunt deleten.

min of meer wat hierboven staat dus

[ Voor 5% gewijzigd door voodooless op 14-01-2008 12:45 ]

[Webgnome]

als je hem implementeerd in je abstract class betekent dat dus dat die methode voor elke subclass dezelfde functionaliteit bied?

Is dat niet zo, aka je hebt maar een implementatie van je abstract waarom dan een abstract?

[ Voor 23% gewijzigd door Webgnome op 14-01-2008 12:46 ]

[Wijnbo]

Ansur schreef op maandag 14 januari 2008 @ 12:43:
Als je in je abstracte klasse geen info hebt om daadwerkelijk die delete() te implementeren, kan je die best niet definiëren daar.

Nee, aangezien mijn abstracte klasse geen idee heeft wat er gedelete gaat worden en of het uberhaupt wel mag. ( Een "LocalRoot" deleten kan bv. niet, net als een "LocalParentFolder")

Mocht je wat basisgegevens hebben, kan je wel bv. al een gedeelte van de logica implementeren, en in je abstracte klasse enkele abstracte functies definiëren (en aanroepen) die je dan in de instanties uitwerkt (om de logica te vervolledigen)

Logica volg ik, maar dit is toch code die nooit van zn lang zal ze leven wordt uitgevoerd? Tenzij ik een super.delete aanroep... aangezien een deel van de code wel het zelfde is is het misschien wel een idee... ( verwijderen uit thumbnailcache, geselecteerde bestandenlijst en bekende bestanden lijst etc... )

Methode leeg laten is gevaarlijk: je kan dan vergeten om voor een bepaalde implementor een uitwerking te voorzien.

Daar heb je een punt. ( Over een maand een avond spenderen waarom een bepaalde methode niets doet heb ik al veel te vaak gedaan )

Een exception gooien is eigenlijk ook niet goed: als je gewoonweg die delete() functie niet definieert in je abstracte klasse, en ze vergeet te implementeren in één van je implementors, zal je een compilatiefout krijgen. Zo weet je ineens dat je nog iets vergeten bent.

Thx

[Wijnbo]

voodooless schreef op maandag 14 januari 2008 @ 12:44:
Als delete in al die implementaties hetzelfde is, dan kun je hem in de abstracte klasse definiëren.

Bepaalde methodes heb ik natuurlijk al in de abstracte staan zoals getPath etc... die is voor elk ding hetzelfde. En moch ie niet hetzelfde zijn ( Een "Root" heeft natuurlijk geen path) dan override ik hem toch gewoon in de implementor?

Heb je niet meerdere implementaties moet je je afvragen waarom je überhaupt een abstracte klasse hebt gemaakt, en als niet alle implementaties kunnen deleten kun je beter een losse Deletable interface maken met de delete methode. Dan kun je simpel met een instanceof checken of je wel of niet kunt deleten.

Ik heb meerdere implementaties En op deze manier zou ik een Deletable, Movable, Openable, Weetikhetwatable klasse krijgen

[voodooless]

StonedKinG34 schreef op maandag 14 januari 2008 @ 12:50:
Bepaalde methodes heb ik natuurlijk al in de abstracte staan zoals getPath etc... die is voor elk ding hetzelfde. En moch ie niet hetzelfde zijn ( Een "Root" heeft natuurlijk geen path) dan override ik hem toch gewoon in de implementor?

Precies! Maar als het overal anders is kun je beter de methode abstract maken.

Ik heb meerdere implementaties En op deze manier zou ik een Deletable, Movable, Openable, Weetikhetwatable klasse krijgen

Juist ja Dat is beter dan om de haverklap exceptions te gooien lijkt me. Maar het zijn dus interfaces, dus het zou er wel eens zo uit kunnen zien:

Java:

public class RMSItem extends LocalItem implements Deletable,Openable{

...
}

Als je dan een item wil deleten:

Java:

item i = ...
if(i instanceof Deletable){
  ((Deletable)i).delete();
} else {
   // laat "jammer dan" error zien ;)
}

[ Voor 21% gewijzigd door voodooless op 14-01-2008 12:59 ]

[Wijnbo]

Voor de duidelijkheid hier mijn structuur:

Item (Interface)
LocalItem (Abstract)				RemoteItem (Abstract)
LocalRoot	LocalFolder	LocalFile	LocalParentFolder	RemoteRoot	RemoteFolder	RemoteFile	RemoteParentFolder

verschil tussen LocalItem en RemoteItem is dat ze geconstruct worden met een File (Java) of een FileConnection (J2ME).

Elke implementatie heeft dus zn eigen delete, rename, en weet ik het wat methodes.

Of iets ook gedelete mag worden bepaal ik volgens in LocalRoot (nee) LocalFodler (ja), etc.
Ook gaat de manier van deleten iets anders per object. (Een folder moet eerst leeg gemaakt worden, een file mag meteen weg, straks komen er nog protected files bij die pas weg mogen na 3 dubbele bevestiging etc).

[Wijnbo]

voodooless schreef op maandag 14 januari 2008 @ 12:53:
[...]

public class RMSItem extends LocalItem implements Deletable,Openable{

...
}
[/code]

Als je dan een item wil deleten:

Java:

item i = ...
if(i instanceof Deletable){
  ((Deletable)i).delete();
} else {
   // laat "jammer dan" error zien ;)
}

Dat kan inderdaad, alleen zit ik dan wel constant te casten. Is dan een boolean in de interface niet handiger? (if item.canRename)

[ Voor 20% gewijzigd door Wijnbo op 14-01-2008 13:02 ]

[voodooless]

Kijk, wat hier al opvalt is eigenlijk dat je twee keer Root, Folder, File en ParantFolder hebt. Dat kun je natuurlijk ook veel handiger doen door daar interfaces van te maken. Misschien had je dat idee ook al gevat.

Java:

public LocalFile extends LocalItem implements File{
   ...
}

Dat is dan handiger dan een Deletable interface

Casten moet je dan inderdaad vaker doen, en aangezien je hier naar een j2me implementatie toe wil moet je ook kijken naar performance, en dan is een simpele boolean misschien sneller. Maar een berg methodes die allemaal niets doen in een klasse omdat ze er eigenlijk niet thuis horen vind ik altijd erg zonde.

[ Voor 30% gewijzigd door voodooless op 14-01-2008 13:08 ]

[BalusC]

edit:
Doet niet meer terzake.

[ Voor 88% gewijzigd door BalusC op 14-01-2008 13:11 ]

[Wijnbo]

voodooless schreef op maandag 14 januari 2008 @ 13:05:
Kijk, wat hier al opvalt is eigenlijk dat je twee keer Root, Folder, File en ParantFolder hebt. Dat kun je natuurlijk ook veel handiger doen door daar interfaces van te maken. Misschien had je dat idee ook al gevat.

Java:

public LocalFile extends LocalItem implements File{
   ...
}

Dat is dan handiger dan een Deletable interface

Casten moet je dan inderdaad vaker doen, en aangezien je hier naar een j2me implementatie toe wil moet je ook kijken naar performance, en dan is een simpele boolean misschien sneller. Maar een berg methodes die allemaal niets doen in een klasse omdat ze er eigenlijk niet thuis horen vind ik altijd erg zonde.

Mn beide abstracte klassen (LocalItem en RemoteItem) implementen Item, dus LocalFile extends Localtem en dus implements Item En aangezien de code van RemoteFile,gebaseerd op de File API totaal anders is dan van LocalFile gebaseerd op de JSR-75 API heeft het dan toch weinig zin om daar interfaces van te bouwen? Of begrijp ik nu iets verkeerd...

edit: zie nu dat je een implements File hebt staan, dat is misschien ook nog wel een idee. Dus eigelijk dit : extends LocalItem implements File terwijl File dan weer Item implement (en LocalItem ook?)

[ Voor 8% gewijzigd door Wijnbo op 14-01-2008 13:19 ]

[voodooless]

StonedKinG34 schreef op maandag 14 januari 2008 @ 13:17:Mn beide abstracte klassen (LocalItem en RemoteItem) implementen Item, dus LocalFile extends Localtem en dus implements Item

Nee! aangezien Localtem al file implementeert doet LocalFile dat automatisch ook en hoef je dat niet nog een keer extra te doen. Als de methodes van Item niet in Localtem geïmplementeerd zijn moet je ze gewoon in LocalFile implementeren.

En aangezien de code van RemoteFile,gebaseerd op de File API totaal anders is dan van LocalFile gebaseerd op de JSR-75 API heeft het dan toch weinig zin om daar interfaces van te bouwen? Of begrijp ik nu iets verkeerd...

Tja, als jij het leuk vindt ok twee verschillende api's te gebruiken... Een File interface is dan makkelijker. De verschillende api's wrap je dan in Local- en RemoteFile. Zo maakt het niet uit waar je het over hebt want het is altijd jou eigen File interface.

File hoeft Item niet te implementeren.

[Wijnbo]

voodooless schreef op maandag 14 januari 2008 @ 13:23:
[...]


Nee! aangezien Localtem al file implementeert doet LocalFile dat automatisch ook en hoef je dat niet nog een keer extra te doen. Als de methodes van Item niet in Localtem geïmplementeerd zijn moet je ze gewoon in LocalFile implementeren.


[...]

Ja dat snapte ik, was alleen ter verduidelijking voor mezelf

^{Zou mooi worden, SuperMagicUltraDevice implements MagicUltraDevice, UltraDevice, Device}

Tja, als jij het leuk vindt ok twee verschillende api's te gebruiken... Een File interface is dan makkelijker. De verschillende api's wrap je dan in Local- en RemoteFile. Zo maakt het niet uit waar je het over hebt want het is altijd jou eigen File interface.

File hoeft Item niet te implementeren.

Het is me duidelijke M'n eigen File dingetje bouwen gaat niet werken, compilen gaat beetje moeilijk als je de File api niet hebt in J2ME

[roy-t]

voodooless schreef op maandag 14 januari 2008 @ 12:44:
Als je een abstracte klasse hebt hebt betekend dat meestal dat je meerder implementaties hebt van deze. Als delete in al die implementaties hetzelfde is, dan kun je hem in de abstracte klasse definiëren. Heb je niet meerdere implementaties moet je je afvragen waarom je überhaupt een abstracte klasse hebt gemaakt, en als niet alle implementaties kunnen deleten kun je beter een losse Deletable interface maken met de delete methode. Dan kun je simpel met een instanceof checken of je wel of niet kunt deleten.

min of meer wat hierboven staat dus

Als je in je abstracte classe (parent) delete hebt dan kun je in een array van die abstracte classe alle childs gooien die dan hun eigen overriden delete functie hebben.

Als je bijvoorbeeld alle items moet deleten van veschillende classen maak je een array van de parent classe en loop je er door heen door telkens .delete() te doen (zorg er wel voor dat delete() geen of altijd dezelfde paramters nodig heeft.

Dus ik snap niet waarom het nut van delete in de abstracte class niet gezien wordt? Of intrepetreer ik het net anders?

[Wijnbo]

roy-t schreef op maandag 14 januari 2008 @ 14:04:
[...]


Als je in je abstracte classe (parent) delete hebt dan kun je in een array van die abstracte classe alle childs gooien die dan hun eigen overriden delete functie hebben.

Als je bijvoorbeeld alle items moet deleten van veschillende classen maak je een array van de parent classe en loop je er door heen door telkens .delete() te doen (zorg er wel voor dat delete() geen of altijd dezelfde paramters nodig heeft.

Dus ik snap niet waarom het nut van delete in de abstracte class niet gezien wordt? Of intrepetreer ik het net anders?

Delete staat al in de interface Vraag was of ie ook geimplementeerd moest worden in de abstracte klasse...

Dus :

Interface - Delete()
Abstracte klasse implements Interface- niets van een Delete() of hooguit een voorbereiding er van.
Blaat extends Abstracte klasse : Daadwerkelijke implementatie van Delete()

[Webgnome]

Wijnbo. Nee dat hoeft dus niet. Hij staat in de Interface en dan moet die worden geimplementeerd. Kun je volstaan met een versie uit je abstract class gooi dan de interface netjes weg en gebruik alleen de abstract.