[Java] Inheritance en enum

[mcdronkz]

Ik ben een applicatie aan het ontwikkelen waarbij ik een bibliotheek simuleer. Deze bibliotheek kan exemplaren van verschillende items uitlenen, waaronder boeken, CD's en DVD's.

De belangrijkste classes:

Item (abstract class)
Item is een abstract class. Item bevat de properties en methods waarover elke subclass van Item sowieso moet beschikken. Het ItemType (enum), de titel, enzovoorts.

Boek/CD/DVD (subclasses van Item)
Deze subclasses van Item bezitten sowieso de properties en methods van Item. Daarnaast bevatten ze over specifieke properties en methods. In het geval van Boek is dat bijvoorbeeld het ISBN nummer.

Exemplaar
Exemplaar is simpelweg een exemplaar van een Item. Ook kan er per Exemplaar opgegeven worden aan wie het is uitgeleend.

Bibliotheek
Doet alles wat je van een bibliotheek zou verwachten. Het uitlenen/terugnemen van exemplaren, toevoegen van leden, overzicht tonen van aanwezige exemplaren, enzovoorts.

Nu heb ik twee vragen.

1. In Boek/CD/DVD vraag ik in de constructor om een titel, omdat elke subclass van Item een titel nodig heeft. Vervolgens gebruik ik super() om deze titel door te geven aan de constructor van Item (de superclass). Dit is an sich geen probleem, maar wanneer ik de constructor van Item ga uitbreiden, moet ik alle subclasses van Item gaan aanpassen. Duidt dit op een slecht ontwerp? Zo ja, hoe zou ik dit kunnen verbeteren?

2. Ik zou graag voor elk Item een categorie willen aanwijzen. Deze categorieën zijn per subclass van Item verschillend. Je kunt je voorstellen dat je bij Boek andere categorieën wilt gebruiken dan bij CD. Nu had ik het plan opgevat om een enum genaamd Categorie te gebruiken. Hoe kan ik per subclass van Item een andere invulling geven aan deze enum? Of moet ik per subclass van Item een andere enum gebruiken, zoals BoekCategorie, CDCategorie, enzovoorts? Dat lijkt me niet wenselijk, omdat ik dan per subclass een andere naam moet gebruiken om de categorie op te vragen.

[Electrowolf]

mcdronkz schreef op zaterdag 17 april 2010 @ 20:28:

Nu heb ik twee vragen.

1. In Boek/CD/DVD vraag ik in de constructor om een titel, omdat elke subclass van Item een titel nodig heeft. Vervolgens gebruik ik super() om deze titel door te geven aan de constructor van Item (de superclass). Dit is an sich geen probleem, maar wanneer ik de constructor van Item ga uitbreiden, moet ik alle subclasses van Item gaan aanpassen. Duidt dit op een slecht ontwerp? Zo ja, hoe zou ik dit kunnen verbeteren?

Je kan gewoon een constructor in item maken zonder parameters en vervolgens in je subclasse de specifieke constructors die je nodig hebt.

2. Ik zou graag voor elk Item een categorie willen aanwijzen. Deze categorieën zijn per subclass van Item verschillend. Je kunt je voorstellen dat je bij Boek andere categorieën wilt gebruiken dan bij CD. Nu had ik het plan opgevat om een enum genaamd Categorie te gebruiken. Hoe kan ik per subclass van Item een andere invulling geven aan deze enum? Of moet ik per subclass van Item een andere enum gebruiken, zoals BoekCategorie, CDCategorie, enzovoorts? Dat lijkt me niet wenselijk, omdat ik dan per subclass een andere naam moet gebruiken om de categorie op te vragen.

Waarom een enum? Naar mijn idee wil je verschillende categorieën maken die los van elkaar staan. Vervolgens kan een item onder nul of meer categorieën vallen. Denk er bv over dat zowel boeken als cd's onder "frans" kunnen vallen.

[Soultaker]

1. [..] wanneer ik de constructor van Item ga uitbreiden, moet ik alle subclasses van Item gaan aanpassen. Duidt dit op een slecht ontwerp?

Ik denk het niet; deze constructie is redelijk gebruikelijk. Wanneer je een base class ontwerpt waarvan allerlei subclasses afgeleid worden moet je van te voren goed nadenken over de interface van die class. Die verandert daarna meestal niet meer. Als je merkt dat je wél steeds base classes moet veranderen op een manier die niet compatible is, dan gaat er waarschijnlijk iets mis bij de analyse of het onderscheid tussen base en subclass deugt niet. Wellicht moet je dan een meer loosely-coupled ontwerp bedenken, maar ik zou daar vooralsnog niet vanuit gaan, want daar kleven ook nadelen aan.

2. [..] Nu had ik het plan opgevat om een enum genaamd Categorie te gebruiken. Hoe kan ik per subclass van Item een andere invulling geven aan deze enum? Of moet ik per subclass van Item een andere enum gebruiken, zoals BoekCategorie, CDCategorie, enzovoorts?

De constructie met BoekCategorie etc. kan niet met Java enums (want die kunnen niet ervan van iets anders dan java.Enum) maar je zou dat wel zelf kunnen uitwerken. Maar wellicht is het beter om helemaal geen aparte classes te maken voor verschilende "soorten" categoriën als die categoriën helemaal geen ander gedrag vertonen.

[mcdronkz]

Electrowolf schreef op zaterdag 17 april 2010 @ 20:52:
[...]


Je kan gewoon een constructor in item maken zonder parameters en vervolgens in je subclasse de specifieke constructors die je nodig hebt.

Ik begrijp wat je bedoeld, maar ik begrijp niet waarom dat mijn software-ontwerp beter maakt. Ik moet sowieso een aantal standaard properties een waarde meegeven. Daarvoor lijkt me een constructor in Item wel zo handig .

[...]


Waarom een enum? Naar mijn idee wil je verschillende categorieën maken die los van elkaar staan. Vervolgens kan een item onder nul of meer categorieën vallen. Denk er bv over dat zowel boeken als cd's onder "frans" kunnen vallen.

Goed punt inderdaad. Eigenlijk zou een Item ook onder meerdere categorieën moeten kunnen vallen.

Soultaker schreef op zaterdag 17 april 2010 @ 20:56:
[...]

Ik denk het niet; deze constructie is redelijk gebruikelijk. Wanneer je een base class ontwerpt waarvan allerlei subclasses afgeleid worden moet je van te voren goed nadenken over de interface van die class. Die verandert daarna meestal niet meer. Als je merkt dat je wél steeds base classes moet veranderen op een manier die niet compatible is, dan gaat er waarschijnlijk iets mis bij de analyse of het onderscheid tussen base en subclass deugt niet. Wellicht moet je dan een meer loosely-coupled ontwerp bedenken, maar ik zou daar vooralsnog niet vanuit gaan, want daar kleven ook nadelen aan.

Oké. Als ik Item goed ontwerp, is er dus eigenlijk niets aan de hand?

[_js_]

ItemType zou in principe niet een enum moeten zijn, want dan moeten alle subklassen van Item van elkaar weten welke enumwaarde ze gebruiken, anders kan iemand die een subklasse toevoegt per ongeluk een enumwaarde hergebruiken..

Exemplaar is niet een klasse, maar een instantie van de Item klasse, die hoort dus niet in deze lijst thuis.

Dat het aanpassen van het publieke deel van een superklasse leidt tot het moeten aanpassen van subklassen is normaal, dat duidt op zichzelf niet op een slecht ontwerp. Dat het nodig is om een superklasse aan te passen wel. In principe zou die op zo'n manier ontworpen moeten zijn dat aanpassingen niet (vaak) nodig zijn.

Wat betreft de categorie-enum, het is vast wel mogelijk om iets te schrijven wat een verschillend enumtype voor elke subklasse geeft, maar ik zie het nut daarvan niet in, als al die enumtypes verschillend zijn dan lijkt het me dat je ze ook niet meer vanuit item als één type kunt behandelen, dus dan is het hele nut van het specificeren van de categorie in Item weg.

offtopic:
Spuit 11, ik zou niet moeten eten tussen het openen van een topic en mijn reply

[ Voor 5% gewijzigd door _js_ op 17-04-2010 21:17 ]

[RayNbow]

_js_ schreef op zaterdag 17 april 2010 @ 21:15:
Exemplaar is niet een klasse, maar een instantie van de Item klasse, die hoort dus niet in deze lijst thuis.

Het boek "The Art of Computer Programming Volume 1" geschreven door D. Knuth en het exemplaar van dat boek dat in m'n boekenkast staat zijn anders toch twee verschillende dingen.

[mcdronkz]

_js_ schreef op zaterdag 17 april 2010 @ 21:15:
ItemType zou in principe niet een enum moeten zijn, want dan moeten alle subklassen van Item van elkaar weten welke enumwaarde ze gebruiken, anders kan iemand die een subklasse toevoegt per ongeluk een enumwaarde hergebruiken..

Klopt inderdaad, dan loop je het risico dat je straks twee subclasses krijgen die allebei een Boek zijn, terwijl dat in werkelijk niet zo is . Hoe zou jij dit doen? Vraag me overigens af of dit echt een probleem is.

Exemplaar is niet een klasse, maar een instantie van de Item klasse, die hoort dus niet in deze lijst thuis.

Zie de post van RayNbow.

Dat het aanpassen van het publieke deel van een superklasse leidt tot het moeten aanpassen van subklassen is normaal, dat duidt op zichzelf niet op een slecht ontwerp. Dat het nodig is om een superklasse aan te passen wel. In principe zou die op zo'n manier ontworpen moeten zijn dat aanpassingen niet (vaak) nodig zijn.

Oké, je bevestigd dus eigenlijk wat Soultaker zegt. Dat moet ik eens even goed in m'n oren gaan knopen .

Wat betreft de categorie-enum, het is vast wel mogelijk om iets te schrijven wat een verschillend enumtype voor elke subklasse geeft, maar ik zie het nut daarvan niet in, als al die enumtypes verschillend zijn dan lijkt het me dat je ze ook niet meer vanuit item als één type kunt behandelen, dus dan is het hele nut van het specificeren van de categorie in Item weg.

Het gaat erom dat ik voor iedere afgeleide van Item één of meer categorieën heb. Ik zat, toen ik dit topic opende, er inderdaad over te denken om verschillende categorieën per subclass aan te houden, maar dit lijkt me beperkt nuttig. Het enige wat er straks kan gebeuren is dat ik straks CD's in de categorie non-fictie heb, dat is niet helemaal wenselijk.

Zouden jullie de categorieën uberhaupt in een enum zetten? Ik zat dan aan een constructie als dit te denken:

- een enum met alle categorieën
- in Item een ArrayList waarin deze categorieën staan (zodat ik ook meerdere categorieën per Item kan gebruiken)
- in Item een method die alle categorieën returned die aan de class gekoppeld zijn

Wel leuk trouwens, object-georiënteerd programmeren en ontwerpen! Dit is een simpel projectje, maar ik heb nu al in de gaten dat je met ontzettend veel dingen rekening moet houden. Lijkt me echt tof als ik dit allemaal een beetje in de vingers krijg.

[ Voor 5% gewijzigd door mcdronkz op 17-04-2010 21:37 ]

[Soultaker]

Een Enum is vooral zinnig als je een statisch aantal waarden hebt. Die waarden moet je immers opgeven in de broncode. Het kan zijn dat de bestaande categoriën vastliggen in je ontwerp en dan zou je ze kunnen hardcoden, maar het is waarschijnlijker dat de categoriën dynamisch zijn en dat je ze in je programma moet kunnen toevoegen en verwijderen. In dat geval is een Enum een slechte keuze omdat je voor nieuwe waarden je code moet aanpassen wat onwenselijk is.

Ik denk dat je categoriën dus beter als instanties van een Categorie klasse kunt modelleren. Dat zijn enum waarden ook in principe, behalve dat je de waarden niet in je code vastlegt. Los daarvan kun je er voor kiezen om verschillende soorten producten in één categorie toe te staan, of niet.

[ Voor 7% gewijzigd door Soultaker op 17-04-2010 22:24 ]

[mcdronkz]

Soultaker schreef op zaterdag 17 april 2010 @ 22:24:
Een Enum is vooral zinnig als je een statisch aantal waarden hebt. Die waarden moet je immers opgeven in de broncode. Het kan zijn dat de bestaande categoriën vastliggen in je ontwerp en dan zou je ze kunnen hardcoden, maar het is waarschijnlijker dat de categoriën dynamisch zijn en dat je ze in je programma moet kunnen toevoegen en verwijderen. In dat geval is een Enum een slechte keuze omdat je voor nieuwe waarden je code moet aanpassen wat onwenselijk is.

Ik denk dat je categoriën dus beter als instanties van een Categorie klasse kunt modelleren. Dat zijn enum waarden ook in principe, behalve dat je de waarden niet in je code vastlegt. Los daarvan kun je er voor kiezen om verschillende soorten producten in één categorie toe te staan, of niet.

Makes sense. Categorieën liggen niet vast in het ontwerp, dus het is eigenlijk niet nodig/handig om ze te hardcoden. Met Items is dat een ander verhaal, voor elk verschillend Item moet ik een subclass maken, omdat het gedrag per Item verschillend kan zijn. De verschillende ItemTypes heb ik daar dus wel gehardcode.

[Haan]

RayNbow schreef op zaterdag 17 april 2010 @ 21:23:
[...]

Het boek "The Art of Computer Programming Volume 1" geschreven door D. Knuth en het exemplaar van dat boek dat in m'n boekenkast staat zijn anders toch twee verschillende dingen.

Het eerste is de beschrijving van een boek (de Item klasse, of Boek die van Item erft), in jouw kast staat een instance van dat boek, bij mij in de kast staat een tweede instance van het boek, wat is je punt?

[mcdronkz]

Haan schreef op zaterdag 17 april 2010 @ 23:00:
[...]

Het eerste is de beschrijving van een boek (de Item klasse, of Boek die van Item erft), in jouw kast staat een instance van dat boek, bij mij in de kast staat een tweede instance van het boek, wat is je punt?

Bij jou in de kast staat een exemplaar van dat boek. Ieder exemplaar heeft z'n eigen kenmerken, denk bijvoorbeeld aan beschadigingen.

[Verwijderd]

De verschillende ItemTypes heb ik daar dus wel gehardcode.

Wat zijn die ItemTypes? Komen die overeen met de class? (als in: Boek, DVD, CD).
Waarom heb je dan een ItemType nodig? Het is niet zo'n goed idee om de class te "dupliceren" in een type enum en vervolgens b.v. switch statements op die enum te baseren.

Bij jou in de kast staat een exemplaar van dat boek. Ieder exemplaar heeft z'n eigen kenmerken, denk bijvoorbeeld aan beschadigingen.

Correct. Je datamodel wordt er wel eenvoudiger van als je "item" en "exemplaar" samenvoegt. Het gevolg is duplicatie van properties. Je krijgt b.v. twee items met de titel "The Art of Computer Programming Volume 1". Of dat erg is in jouw situatie kan ik niet inschatten

[mcdronkz]

Verwijderd schreef op zondag 18 april 2010 @ 00:07:
[...]


Wat zijn die ItemTypes? Komen die overeen met de class? (als in: Boek, DVD, CD).
Waarom heb je dan een ItemType nodig? Het is niet zo'n goed idee om de class te "dupliceren" in een type enum en vervolgens b.v. switch statements op die enum te baseren.

Ja, die komen in principe overeen met de namen van de subclasses van Item. Ik zou ook op één of andere manier het type van de class kunnen achterhalen en dat gebruiken, maar ik vraag me af of dat de bedoeling is .

[...]

Correct. Je datamodel wordt er wel eenvoudiger van als je "item" en "exemplaar" samenvoegt. Het gevolg is duplicatie van properties. Je krijgt b.v. twee items met de titel "The Art of Computer Programming Volume 1". Of dat erg is in jouw situatie kan ik niet inschatten

Duplicatie van properties? Ik krijg maar één Item met die titel, en één Exemplaar die dat Item bevat in de property 'Item exemplaarVan'.

Ik heb nog wat code bijgevoegd van de implementatie van categorieën:

Java:

public class Categorie 
{
    private String naam;
    
    public Categorie(String naam)
    {
        setNaam(naam);
    }
    
    public String getNaam()
    {
        return this.naam;
    }
    
    public void setNaam(String naam)
    {
        this.naam = naam;
    }
    
    public String toString()
    {
        return getNaam();
    }
}

Java:

import java.util.*;

public abstract class Item
{
    public enum ItemType {Boek, CD, DVD};
    protected ItemType itemType;
    protected ArrayList<Categorie> categorieën;
    protected String titel;
    
    public Item(ItemType itemType, ArrayList<Categorie> categorieën, String titel)
    {
        setItemType(itemType);
        this.categorieën = new ArrayList<Categorie>();
        setCategorieën(categorieën);
        setTitel(titel);
    }
    
    /**
     * Laat zien tot welke categorieën het item behoort.
     */
    public ArrayList<Categorie> getCategorieën()
    {
        return categorieën;   
    }
    
    /**
     * Leg vast tot welke categorieën het item behoort.
     */
    public void setCategorieën(ArrayList<Categorie> categorieën)
    {
        this.categorieën = categorieën;
    }
    
    /**
     * Koppel een categorie aan het item.
     */
    public void voegCategorieToe(Categorie categorie)
    {
        categorieën.add(categorie);
    }
}

Lijkt me een vrij correcte manier, toch?

offtopic:
En ja, misschien zijn trema's in namen van variabelen niet zo handig, maar 't werkt wel

[RayNbow]

Haan schreef op zaterdag 17 april 2010 @ 23:00:
[...]

Het eerste is de beschrijving van een boek (de Item klasse, of Boek die van Item erft), in jouw kast staat een instance van dat boek, bij mij in de kast staat een tweede instance van het boek, wat is je punt?

Juist, dat boek. Niet een boek.

Het laatste zou dit betekenen...

Java:

Auteur knuth = Auteur("D. Knuth");
Boek mijnBoek = Boek("TAOCPv1", knuth);
Boek jouwBoek = Boek("TAOCPv1", knuth);

...waarbij er geen enkele relatie is tussen mijnBoek en jouwBoek, op de auteur na.

Het eerste zou strict iets betekenen als...

Java:

Boek mijnBoek = TAOCPv1();
Boek jouwBoek = TAOCPv1();

...maar werkt totaal niet in een class-based taal aangezien je niet voor elk geschreven boek van tevoren een class kunt maken.

Vandaar ook het het onderscheid tussen een bepaald boek en zijn exemplaren, met elkaar verbonden d.m.v. compositie. Zelf gebruik ik het liefst de termen BookTitle en BookCopy voor de twee verschillende concepten. Het Nederlandse woord "boek" is ambigu en kan voor beide concepten worden gebruikt.


In een prototype-based taal heb je trouwens niet het probleem van "classes" op verschillende niveaus, maar kan elk object weer als een soort van class dienen:

JavaScript:

function Title(title, author) {
    this.title = title;
    this.author = author;
}

function Book(title, author, pages) {
    Title.call(this, title, author);
    this.pages = pages;
}
Book.prototype = new Title;
Book.prototype.constructor = Book;
Book.prototype.Copy = function(owner) {
    var copy = function(){};
    copy.prototype = this;
    copy = new copy();
    copy.owner = owner;
    return copy;
}

taocp = new Book("The Art of Computer Programming", "D. Knuth", 896);
myBook = taocp.Copy("RayNbow");
yourBook = taocp.Copy("Haan");

[mcdronkz]

Wanneer ik een nieuw Exemplaar toevoeg binnen Bilbiotheek, moet ik altijd een verwijzing naar een Item object opgeven. Binnen BlueJ maak ik dus eerst altijd een Item object aan, en de naam van dat object geef ik dan gewoon door aan voegExemplaarToe().

Ik beheer dus geen lijst met verschillende items. Er kan dus ook geen overzicht van items getoond worden, alleen van de exemplaren.

Mijn vragen zijn als volgt:

1. Graag zou ik zo'n lijst van Items (ArrayList) willen toevoegen, maar ik weet niet zo goed waar ik dat moet doen. Is Bibliotheek de juiste plek om de lijst met items bij te houden? Voor exemplaren is het logisch dat ze in een bibliotheek staan, maar bij items twijfel ik.

2.Ik wil een overzicht kunnen tonen van de verschillende items. Echter, hoe kan ik het beste omgaan met specifieke properties die bij de verschillende items horen? Ik heb niet zoveel zin om conditional statements te maken in de functie waarin ik het overzicht van items print. Is het verstandig om per Item de toString() functie te overriden, zodat ik daarin de informatie kan plaatsen die ik wil laten zien in het overzicht?

Ik moet dan ook m'n voegExemplaarToe() methode aanpassen zodat ik een item kan kiezen dat in de ArrayList staat, maar dat zal wel lukken .

Types van items heb ik nu als volgt opgelost:

Java:

/**
* Laat het type van het item zien.
*/
public String getType()
{
    return this.getClass().getName();
}

[ Voor 20% gewijzigd door mcdronkz op 18-04-2010 16:47 ]

[YopY]

mcdronkz schreef op zaterdag 17 april 2010 @ 20:28:
1. In Boek/CD/DVD vraag ik in de constructor om een titel, omdat elke subclass van Item een titel nodig heeft. Vervolgens gebruik ik super() om deze titel door te geven aan de constructor van Item (de superclass). Dit is an sich geen probleem, maar wanneer ik de constructor van Item ga uitbreiden, moet ik alle subclasses van Item gaan aanpassen. Duidt dit op een slecht ontwerp? Zo ja, hoe zou ik dit kunnen verbeteren?

2. Ik zou graag voor elk Item een categorie willen aanwijzen. Deze categorieën zijn per subclass van Item verschillend. Je kunt je voorstellen dat je bij Boek andere categorieën wilt gebruiken dan bij CD. Nu had ik het plan opgevat om een enum genaamd Categorie te gebruiken. Hoe kan ik per subclass van Item een andere invulling geven aan deze enum? Of moet ik per subclass van Item een andere enum gebruiken, zoals BoekCategorie, CDCategorie, enzovoorts? Dat lijkt me niet wenselijk, omdat ik dan per subclass een andere naam moet gebruiken om de categorie op te vragen.

Een enum kun je inderdaad niet extenden, echter, een enum kan wel een interface implementeren. Dusch, maak een interface Category, en een concrete enum BookCategory, AlbumCategory, MovieCategory (of Genre, wat je maar belieft). Alle functies die 'een' category verwachten (zoals misschien een aantal functies in je Item) kun je één van dit soort enums geven.

Ik zou alleen wel iets specifieker zijn in je subclasses - je wilt niet dat iemand een BookCategory kan instellen op een Album. Je zou iets met generics kunnen doen misschien, waarbij je Item volledig abstract laat en Book of Album het type categorie laat specificeren.

quote: _js_

Exemplaar is niet een klasse, maar een instantie van de Item klasse, die hoort dus niet in deze lijst thuis.

Maar een Item kun je niet aan twee personen tegelijk uitlenen. Hoe zou je dat probleem anders modelleren dan?

Wel leuk trouwens, object-georiënteerd programmeren en ontwerpen! Dit is een simpel projectje, maar ik heb nu al in de gaten dat je met ontzettend veel dingen rekening moet houden. Lijkt me echt tof als ik dit allemaal een beetje in de vingers krijg.

. Je zult waarschijnlijk al snel jezelf erop betrappen dat je je applicatie telkens opnieuw refactord om maar net iets beter te zijn. Doe ik ook, .

quote: mcdronkz

Makes sense. Categorieën liggen niet vast in het ontwerp, dus het is eigenlijk niet nodig/handig om ze te hardcoden. Met Items is dat een ander verhaal, voor elk verschillend Item moet ik een subclass maken, omdat het gedrag per Item verschillend kan zijn. De verschillende ItemTypes heb ik daar dus wel gehardcode.

Niet beslist - je zou bijvoorbeeld ook een generiek type Item kunnen maken met een 'type' veld, waarbij je in je applicatie de naam 'boek' aan toekent. Vervolgens een Map van properties, zodat je heeel algemeen een item kunt maken met properties zoals ISBN, Titel, Categorie, Schrijver, Vertaler, en VindtIkHemLeuk in je applicatie zelf. Want, als je heel eerlijk bent, wat voor specifieke functionaliteit zit er in een klasse Boek of CD, anders dan setDit en setDat?

1. Graag zou ik zo'n lijst van Items (ArrayList) willen toevoegen, maar ik weet niet zo goed waar ik dat moet doen. Is Bibliotheek de juiste plek om de lijst met items bij te houden? Voor exemplaren is het logisch dat ze in een bibliotheek staan, maar bij items twijfel ik.

class ItemArchief? BoekUitgeverij? (nee, ik ben niet helemaal serieus, ).

Dit soort dingen staan vaak in een Data Access Object, een tussenlaag tussen je opslag (een database, of, als je wilt, gewoon het geheugen, dwz een ArrayList of Map waar je Items in staan) en je systeem. Zoek dat eens op.

2.Ik wil een overzicht kunnen tonen van de verschillende items. Echter, hoe kan ik het beste omgaan met specifieke properties die bij de verschillende items horen? Ik heb niet zoveel zin om conditional statements te maken in de functie waarin ik het overzicht van items print. Is het verstandig om per Item de toString() functie te overriden, zodat ik daarin de informatie kan plaatsen die ik wil laten zien in het overzicht?

Als je, zoals ik hierboven beschrijf, zo'n structuur maak kun je dat doen ja. De toString() overriden is ook een optie, maar dat wordt meer gebruikt om te debuggen, dat je de inhoud van je object even naar de console toe schrijft. Voor dit soort problemen, dwz het scheiden van het algoritme (weergeven van properties van een iem) van de objectstructuur waar het op werkt (dwz je Boek, Album, etc), hebben de slimme mensen het Visitor pattern uitgevonden: Wikipedia: Visitor pattern.