[.NET/Java] OO met db Koppeling

[Verwijderd]

Zelf doe ik al bijna een jaar object georiënteerd programmeren in ASP.NET en nu krijg ik sinds een aantal weken object georiënteerd programmeren op school. De methoden en manier van programmeren die mijn leraar gebruikt zijn alleen helemaal anders zoals ik mezelf hebt aangeleerd.

Als we ff als voorbeeld nemen een database met 2 tabellen

Menus
Categories

Velden zijn verder niet belangrijk denk ik, mijn leraar op school zal dit in java als volgt aanpakken (kan best zijn dat hier en daar klein foutje in code zit maar daar gaat het ff niet om):

code:

class Menu
{
    private Vector categories;

    public void addCat(string name)
    {
        Category a = new Category(name);
        categories.add(a)
    }   
}

class Category
{
    private string name;
    public Category(string name)
    {
        this.name = name;
    }
}

Maar dat ik dus niet zoals ik het mezelf heb aangeleerd, zelf zou ik het zo doen:

code:

class Menu
{
    private Categories Cats;

    public Categories getCats()
    {
        return Cats;
    }   
}

class Categories
{
    private Vector elements;
    public void add(string name)
    {
        Category a = new Category(name);
        elements.add(a);
    }
}

class Category
{
    private string name;
    public Category(string name)
    {
        this.name = name;
    }
}

Maar dat is volgens mijn leraar helemaal fout omdat de class Menu de categories beheerd en daarom moet de add methoden daarin zitten, ook al doet microsoft het met .NET ook altijd zo via bijvoorbeeld die CollectionBase class.

Volgens mij zijn beide manieren gewoon goed ik zie niet echt voor of nadelen behalve dan dat mijn manier iets meer tikwerk is maar daardoor naar mijn idee ook een stuk duidelijker.

Mijn vraag is eigenlijk, hoe zit het nou precies, welke manier is nou de manier, of zijn het gewoon twee verschillende standaarden of doe ik het gewoon helemaal fout?

[Vedett.]

Tja, iedereen heeft zo zijn methoden.

Maar eigenlijk komt het erop neer dat jij nog een collectie class maakt voor de class categorie, namelijk categories. Voor de rest is er weinig verschil.

Als je toch je categories class wilt beheren in de menu class (zoals jij het zou doen). Zou je in plaats van dit

code:

class Menu
{
    private Categories Cats;

    public Categories getCats()
    {
        return Cats;
    }    
}

dit kunnen doen

code:

class Menu
{
    private Categories Cats;

    public Categorie getCat(id)
    {
        return Cats[0];
    }    
  
    public void addCategorie(Categorie categorie)
    {
        Cats.add(categorie)
    }

}

Dan heeft dat argument van je leraar afgedaan.

Wat nu goed of wat nu fout is, hang helemaal af van hoe je de Menu class wilt gebruiken en hoe je alles wilt limiteren.

Ikzelf zou jouw manier nemen. Hoewel ik in de add methode van de Categories class de parameter van het type Categorie zou nemen ipv het type string.

[mulder]

Ik denk meer dat je leraar een one-trick-pony is, beide manieren zijn imho een prima oplossing en dan zou ik eerder kiezen voor jouw methode. Er zijn meerdere wegen naar Rome, er is wat dat betreft geen 'standaard'

[ Voor 10% gewijzigd door mulder op 15-02-2006 17:44 ]

[Verwijderd]

Ik heb meer vertrouwen in de methode van je leraar. Wat is volgens jou de toegevoegde waarde van een Categories object?

[Vedett.]

Die extra collectie zou ik inderdaad ook weg laten. Maar het argument van die leraar heeft daar totaal geen betrekking op.

Je kan de Categories volledig beheren in Menu. Daarvoor hoef je geen method addCategorie te voorzien die enkel maar een string aanvardt. Dat zou imho een Categorie object moeten zijn.

Vervolgens is het een kwestie van de hele collectie te verbergen van de buitenwereld.

[Orphix]

Of dit goed of fout is kan je niks zinnigs over zeggen zonder de context. Pas wanneer de verantwoordelijkheden van alle classes bekend zijn kan je zeggen of de opzet goed is.

[Verwijderd]

het is niet fout of goed. maar jou manier kost het meer (je moet immers een object aanmaken). de manier van je leraar is dit niet het geval.

bij kleine applicatie is dit te verwaarlozen maar als het een onderdeel is van een grote applicatie gaat dit ten koste van de performance.

[Gert]

Categories lijkt mij een directe vertaling van een koppeltabel in de db, en dat zijn geen losstaande objecten.

[Sv3n]

Ik denk dat wat jou leraar bedoeld is het volgende:
Jij maakt een aparte class Categories die totaal geen nut heeft (niet op dit moment iig.) omdat je eigenlijk alleen maar een object maakt en de standaard functies van een collection aanroept (en alleen maar een collectie beheert dus, waarom een aparte class maken?), waarom zou dat niet kunnen in menu. Je leraar bedoelt dus(denk ik) dat de collectie in de class menu moet zitten, en dus een add methode moet hebben omdat de Categories class overbodig is

Jouw methode werkt wel hoor, maar er zit gewoon een overbodige class in, op school willen ze je het op een goede manier leren en dat is dus niet met een nutteloze class