[JAVA] Bang voor verkeerde aanpak

[Verwijderd]

Ik ben sinds een tijdje bezig met java, maar ik heb het gevoel dat mijn structuur toch fout zit (ik kan niet beschrijven waarom, maar zo voelt het ).

Ik denk dat ik het het beste kan beschrijven aan de hand van 2 van mijn classes, zodat jullie kunnen zien hoe deze met elkaar werken, let wel: dit is geen scriptrequest of zoek de bugs, maar ik vraag puur om tips om mijn structuur te verbeteren.

Java:

//Database.java
package bean;

import java.sql.*;
import interfaces.DatabaseInformation;

public class Database implements DatabaseInformation {
    
    // classe variabelen
    public ResultSet resultset = null;
    public Connection connection = null;
    public Statement statement = null; 

    // constructor
    public Database() {
    
    }
    
    // opent de verbinding met de database en geeft een connection object terug
    public Connection openConnection() {
        try {
            Class.forName(DatabaseInformation.databaseDriver);
            connection = DriverManager.getConnection(DatabaseInformation.databaseConnection);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        return connection;
    }
    
    // sluit de verbinding met de database
    public void closeConnection(Connection c) {
        try {
            c.close();
        } catch(Exception e) {
            e.printStackTrace();
        }
    } 
    
    
    // voert een selectie query uit op de database
    public ResultSet handleSelectQuery(String q, Connection c) {
        try {
            statement = c.createStatement();
            resultset = statement.executeQuery(q);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        return resultset;
    }
    
    
    // voert een query uit op de database (delete, update, insert etc)
    public boolean handleUpdateQuery(String q, Connection c) {
        boolean succes = false;
        try {
            statement = c.createStatement();
            statement.executeUpdate(q);
            succes = true;
        } catch(Exception e) {
            e.printStackTrace();
        }
        return succes;
    }
}

Java:

// Artikelsoort.java
// Om de code wat in te korten heb ik de get en set methoden verwijderd uit dit voorbeeld
package bean;

import java.util.Vector;
import java.sql.*;
import bean.Database;
import interfaces.DatabaseInformation;

public class Artikelsoort {
    
    private int soortid;
    private String naam;
    private int btw;
    private String verhuur;
    
    private String SQLString;
    private Database database = new Database();
    
    private Connection connection = database.openConnection();
    private ResultSet resultset = null;
    private Statement statement = null;
    
    public Artikelsoort() {
    }
   
    public Artikelsoort returnArtikelsoort(int id) {
        Artikelsoort artikelSoort = new Artikelsoort();
               
        SQLString = "SELECT * FROM artikelsoort WHERE soortid = "+ id;
        try {
           resultset = database.handleSelectQuery(SQLString, connection);
           while (resultset.next()) {
                artikelSoort.setSoortid(resultset.getInt(DatabaseInformation.ARTIKELSOORT_TBL_SOORTID));
                artikelSoort.setNaam(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_NAAM));
                artikelSoort.setVerhuur(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_VERHUUR));
                artikelSoort.setBtw(Integer.parseInt(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_BTW)));
           }
        } catch(Exception e) {
            e.printStackTrace();
        }
               
        return artikelSoort;
    }
    
    public Vector returnArtikelsoortLijst() {
        Vector artikelSoortLijst = new Vector();
        SQLString = "SELECT * FROM artikelsoort";
        try {
            resultset = database.handleSelectQuery(SQLString, connection);
           while (resultset.next()) {
                Artikelsoort artikelSoort = new Artikelsoort();
                artikelSoort.setSoortid(resultset.getInt(DatabaseInformation.ARTIKELSOORT_TBL_SOORTID));
                artikelSoort.setNaam(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_NAAM));
                artikelSoort.setVerhuur(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_VERHUUR));
                artikelSoort.setBtw(Integer.parseInt(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_BTW)));
                artikelSoortLijst.addElement(artikelSoort);
           }
        } catch(Exception e) {
            e.printStackTrace();
        }
        return artikelSoortLijst;
    }
}

Ik hoop dat jullie me een schop in de goede richting kunnen geven

[Confusion]

Niet structureel:
- Variabelen als 'q' en 'c' zeggen niet zoveel. Noem ze 'query' en 'conn' of zelfs 'connection'.
- Niet Exception afvangen, maar alleen de excepties die daadwerkelijk gegooid worden.
- Lege constructors: ofwel een comment "//empty" of weglaten, omdat de no-argument constructor toch automatisch gegenereerd wordt als er geen andere is.
- Klasse variabelen die object zijn hoef je niet op null te initialiseren; dat gebeurt vanzelf al.
- Als je structuur niet threadsafe hoeft te zijn, gebruik dan een ArrayList in plaats van een Vector

[Verwijderd]

Oke, ga ik aan werken

[ Voor 77% gewijzigd door Verwijderd op 09-03-2006 20:25 ]

[.oisyn]

Confusion schreef op donderdag 09 maart 2006 @ 20:23:
- Lege constructors: ofwel een comment "//empty" of weglaten, omdat de no-argument constructor toch automatisch gegenereerd wordt als er geen andere is.

Tja, waarom? Wat is er mis met een lege constructor? En een comment erin verandert daar natuurlijk weinig aan . Bovendien heb je de lege constructor alsnog nodig als je naast de default constructor ook nog een andere constructor wilt hebben. De defaultconstructor zal niet meer gegenereerd worden op het moment dat je een constructor definieert, dus dan zit je alsnog met een lege constructor

[mbravenboer]

Ik pak er even twee problemen uit. Uiteraard valt er veel meer over te zeggen, maar daar zijn er hier mensen genoeg voor .

code:

    private String SQLString;

Dit is wat vreemd: je gebruikt deze String alleen per methode, dus er is eigenlijk geen reden om dit een veld van de klasse te maken. Je kan het beter een lokale variabele laten zijn.

Dit is niet slechts een kwestie van stijl: het kan zelfs een serieus (security) probleem worden. Als je wellicht later je applicatie multi-threaded gaat maken, kan het zijn dat een andere, concurrent, methode aanroep dit veld aanpast voordat jij het daadwerkelijk gaat gebruiken om de query uit te voeren in een andere methode. Deze ongewenste interleaving van statements kan volledig onvoorspelbaar gedrag opleveren, zoals bijvoorbeeld opeens de gegevens zien van een andere gebruiker.

code:

        SQLString = "SELECT * FROM artikelsoort WHERE soortid = "+ id;

Dit is ook een interessant probleem. In dit geval gaat het het construeren van een sql query op deze manier nog goed, maar als je iets vergelijkbaars met een string waarde doet, heb je een serieus security probleem: een SQL injection. De gebruiker kan voor de string willekeurige onderdelen van een SQL query intikken, waardoor hij bijvoorbeeld meer data kan zien dan wat oorspronkelijk de bedoeling was.

De meest praktische oplossing hiervoor is om een PreparedStatement te gebruiken met ? voor de 'gaten' in je query. Die kan je via methode aanroepen invullen.

Deze problemen zijn even belangrijker als de structuur en de stijl en worden natuurlijk enorm belangrijk als je zo'n applicatie ook daadwerkelijk gaat deployen.

[Verwijderd]

Dank je voor je tips, op security niveau zijn we nog niet aanbeland, maar zal er eens naar googleen

[TlighT]

Wat me als eerste opvalt, is dat je methods om artikelsoort entiteit(en) op te halen niet static zijn. Dat is een beetje vreemd, want nu dien je eerst een artikelsoort te instantieren waarna je pas returnArtikelsoort aan kan roepen, die nog eens een extra artikelsoort instantieert.

Dus ik zou iig de database-methods static maken:

Java:

public static Artikelsoort returnArtikelsoort(int id) {
     Artikelsoort artikelSoort = new Artikelsoort();
     ...     
     return artikelSoort;
}

Zodat je kunt doen:

Java:

Artikelsoort foo = Artikelsoort.returnArtikelsoort(20);

Mooier vind ik vaak de database functionaliteit te scheiden van de entiteit en in een aparte "manager" klasse te plaatsen, zodat je bijv. krijgt:

Java:

ArtikelsoortManager artikelsoortMgr = new ArtikelsoortManager();
Artikelsoort foo = ArtikelsoortMgr.returnArtikelsoort(20);

En als je productiecode schrijft, zou ik op zoek gaan naar een (eenvoudige) or-mapper. Bijvoorbeeld Ibatis sqlmaps is erg eenvoudig te gebruiken en scheelt je een hoop werk. Als je het alleen maar gaat om het oefenen, hoeft dat natuurlijk niet.

Qua stijl zou ik iig het meeste in het engels houden, dus niet Atikelsoort maar bijv. ArticleType, maar dat is meer persoonlijk.

[Verwijderd]

Het is geen productiecode, het is een schoolprojectje.
Ik ben alleen niet zo tevreden met de code en wil het graag een beetje verbeteren

[itsalwaysme]

ik zou om te beginnen geen public variabelen in een classe declareren, maar het via get en set functies beschikbaar maken van deze variabelen. (zie ook artikels over OO programmeren)
zoals eerder gezegd, de lege constructor: je kan hem er neer zetten, maar java genereerd automatisch een constructor als deze niet bestaat. (het is wat je zelf het beste lijkt, maar ik zou hem weg laten)

[Verwijderd]

nvm. stomme vraag

[ Voor 100% gewijzigd door Verwijderd op 09-03-2006 22:20 ]

[Confusion]

.oisyn schreef op donderdag 09 maart 2006 @ 20:32:
Tja, waarom? Wat is er mis met een lege constructor? En een comment erin verandert daar natuurlijk weinig aan . Bovendien heb je de lege constructor alsnog nodig als je naast de default constructor ook nog een andere constructor wilt hebben. De defaultconstructor zal niet meer gegenereerd worden op het moment dat je een constructor definieert, dus dan zit je alsnog met een lege constructor

offtopic:
Codeblokken zijn zelden leeg, dus een leeg codeblok roept een vraag op: is er misschien iets vergeten? Evenzo roept een enkele parameterloze constructor de vraag op of er misschien meerdere zouden moeten zijn. Waarom is deze er? Is er met refactoren iets misgegaan? Hoe meer code en hoe meer 'afwijkende' dingen, hoe meer kleine vragen die even je aandacht opeisen. Hoe duidelijker je bent, ook om triviale dingen weg te vangen, hoe makkelijker het te begrijpen wordt. Daarom: in ieder lege codeblok een comment en overbodige parameterloze constructors weglaten. Vele kleintjes maken een grote.

[.oisyn]

Tja, wat je zegt is allemaal nogal subjectief. Ik zou zelf bijvoorbeeld niet raar staan te kijken van een lege constructor - wat iets anders is dan zomaar een leeg code blok. Daarnaast is het tijdens het debuggen rete-handig omdat je dan een breakpoint kunt plaatsen op de constructor. Maar goed, ik ben dan ook een C++ programmeur, waar je je classmembers initialiseert dmv een initializerlist in de definitie van de constructor. En aangezien primitives niet default geinitialiseerd worden...

[bvp]

Its_always_me schreef op donderdag 09 maart 2006 @ 21:05:
ik zou om te beginnen geen public variabelen in een classe declareren, maar het via get en set functies beschikbaar maken van deze variabelen. (zie ook artikels over OO programmeren)
zoals eerder gezegd, de lege constructor: je kan hem er neer zetten, maar java genereerd automatisch een constructor als deze niet bestaat. (het is wat je zelf het beste lijkt, maar ik zou hem weg laten)

Om hier nog even iets verder op in te gaan.
Je gebruikt in je class Database locale public variabelen > deze mogen private en kun je ophalen met bijv. public Connection getConnection(); > hoeven ook niet met null gedeclareerd te zijn, want zijn ze toch al.
Verder gebruik je deze variablen vrijwel niet aangezien je hier in openConnection() de connection terug geeft en dit Connection-object in elke method-call weer meegeeft.
Beter is dan dus om hier ook gebruik te maken van deze class-variablen. Zo houd je de verantwoordelijkheden bij de class zelf.

[Tubby]

Bekijk het DAO pattern eens (evt incl DaoFactory)
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Globaal zou het er dan als volgt uit komen te zien.

Java:

import java.sql.*;
import interfaces.DatabaseInformation;

public class GeneralDao implements DatabaseInformation {
    
    // classe variabelen
    public ResultSet resultset = null;
    public Connection connection = null;
    public Statement statement = null; 

    // constructor
    public GeneralDao() {
    
    }
    
    // opent de verbinding met de database en geeft een connection object terug
    // dit zou je beter met een connection pooling pattern kunnen doen ivm de tijd die het kost om een connection te openen.
    public Connection openConnection() {
        try {
            Class.forName(DatabaseInformation.databaseDriver);
            connection = DriverManager.getConnection(DatabaseInformation.databaseConnection);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        return connection;
    }
    
    // sluit de verbinding met de database
    public void closeConnection(Connection c) {
        try {
            c.close();
        } catch(Exception e) {
            e.printStackTrace();
        }
    } 
    
    
    // voert een selectie query uit op de database
    public ResultSet handleSelectQuery(String q, Connection c) {
        try {
            statement = c.createStatement();
            resultset = statement.executeQuery(q);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        return resultset;
    }
}

Java:

public class ArtikelsoortDao extends GeneralDao {
    
    public Artikelsoort returnArtikelsoort(int id) {
        Artikelsoort artikelSoort = new Artikelsoort();
               
        SQLString = "SELECT * FROM artikelsoort WHERE soortid = "+ id;
        try {
           resultset = super.handleSelectQuery(SQLString, connection);
           while (resultset.next()) {
                artikelSoort.setSoortid(resultset.getInt(DatabaseInformation.ARTIKELSOORT_TBL_SOORTID));
                artikelSoort.setNaam(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_NAAM));
                artikelSoort.setVerhuur(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_VERHUUR));
                artikelSoort.setBtw(Integer.parseInt(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_BTW)));
           }
        } catch(Exception e) {
            e.printStackTrace();
        }
               
        return artikelSoort;
    }
}

Java:

// Artikelsoort.java
public class Artikelsoort {
    
    private int soortid;
    private String naam;
    private int btw;
    private String verhuur;
    
    //getters, setters etc
}

Dit is natuurlijk geen werkend geheel, maar ik hoop dat het principe duidelijk is. Een soort superdao waarbij de de standaard dao function in onderbrengt (eventueel protected). Alle dao's extend je daarvan waarin de specifieke database functies per type dataobject in zitten.

Wellicht moet je ook eens kijken naar het connection pooling pattern voor het uitdelen van je db connections.

Het creeren van DAO's zou je met een DaoFactory kunnen doen (google op factory pattern)

En dan heb ik het gebruik van named parameters voor je sql queries even achterwege gelaten, maar dat moet je natuurlijk wel doen ter voorkoming van sql injection.

[ Voor 15% gewijzigd door Tubby op 10-03-2006 09:17 ]

[sig69]

Wat op mij vreemd overkomt is dat je in de class ArtikelSoort een connection hebt. Waarom heb je die nodig? Je hebt al een class Database, die zou prima in het begin van de handleSelect een connectie naar de database kunnen openen, en daarna ook sluiten. Dat zie ik hier overigens nergens in je code terug, zodra je een instantie van de class Artikelsoort maakt, wordt er een database connectie geopend en nergens gesloten.

[Tubby]

sig69 schreef op vrijdag 10 maart 2006 @ 09:21:
Wat op mij vreemd overkomt is dat je in de class ArtikelSoort een connection hebt. Waarom heb je die nodig? Je hebt al een class Database, die zou prima in het begin van de handleSelect een connectie naar de database kunnen openen, en daarna ook sluiten. Dat zie ik hier overigens nergens in je code terug, zodra je een instantie van de class Artikelsoort maakt, wordt er een database connectie geopend en nergens gesloten.

Dat is de reden waarom je beter kunt kijken naar een connection pooling package.
http://sourceforge.net/projects/c3p0 is een goed voorbeeld

[Verwijderd]

Wat op mij vreemd overkomt is dat je in de class ArtikelSoort een connection hebt. Waarom heb je die nodig? Je hebt al een class Database, die zou prima in het begin van de handleSelect een connectie naar de database kunnen openen, en daarna ook sluiten. Dat zie ik hier overigens nergens in je code terug, zodra je een instantie van de class Artikelsoort maakt, wordt er een database connectie geopend en nergens gesloten.

Dat heb ik gedaan om de volgende reden (na verandering van wat code):

Java:

String SQLString = "DELETE FROM artikelsoort WHERE soortid = ?";
try {
    preparedstatement = connection.prepareStatement(SQLString);
    preparedstatement.setInt(1, id);
    database.handleUpdateQuery(preparedstatement);

Ik heb een Connection object nodig voor prepareStatement (dacht ik ), in Artikelsoort.java wordt een statement voorbereid, en deze wordt aan mijn Database.java doorgegeven voor uitvoer.

[ Voor 8% gewijzigd door Verwijderd op 10-03-2006 11:53 ]

[bvp]

Verwijderd schreef op vrijdag 10 maart 2006 @ 11:50:
[...]

Ik heb een Connection object nodig voor prepareStatement (dacht ik ), in Artikelsoort.java wordt een statement voorbereid, en deze wordt aan mijn Database.java doorgegeven voor uitvoer.

Klopt maar dat probeerde ik en Sig69 strx al te zeggen.
Je hebt een private Connection gedeclareerd in je Database-class.
Waarom gebruik je deze niet gewoon, hoef je dit object dus ook niet mee te geven in je method-signature.

[Verwijderd]

Ah volgens mij snap ik wel wat je bedoelt, ik had je code voorbeeld niet goed gelezen, ik moet Database als parent van Artikelsoort zien, zodat Artikelsoort alle leden van Database erft en ik deze niet opnieuw hoef te declareren in Artikelsoort, right?

[whoami]

Je bedoeld dat je ArtikelSoort zou laten inheriten van Database ?
Een artikelsoort IS toch geen database ?
Je zou wel gebruik kunnen maken van Database in ArtikelSoort.

[Verwijderd]

Maar dat is toch precies hetzelfde als wat Tubby ter voorbeeld geeft:

Java:

public class GeneralDao implements DatabaseInformation {

Java:

public class ArtikelsoortDao extends GeneralDao {

Of zie ik dat verkeerd?

[Tubby]

Nee, DAO is een Data Access Object. Een object bedoeld om jouw ArtikelSoort instantie uit de database te krijgen. In mijn voorbeeld zie je dat ArtikelSoort een class is met alleen nog de properties en getters en setters (een POJO, plain old java object )

[whoami]

Hmm, Tubby maakt een Dao class die inherit van GeneralDao die op z'n beurt inherit van DatabaseInformation.
Tubby zorgt voor een scheiding tussen je database-toegang en je informatie zelf. Dat is iets waar ik ook naartoe wou.
Hij heeft de ArtikelSoort class dus eigenlijk in 2 getrokken: een class die echt de informatie en gedrag bevat van één ArtikelSoort, en een Dao class waarmee je een ArtikelSoort uit de database kan halen, of er kan in stoppen.

[Kwistnix]

Verwijderd schreef op vrijdag 10 maart 2006 @ 13:10:
Maar dat is toch precies hetzelfde als wat Tubby ter voorbeeld geeft:

Java:

public class GeneralDao implements DatabaseInformation {

Java:

public class ArtikelsoortDao extends GeneralDao {

Of zie ik dat verkeerd?

Dat zie je verkeerd want dat is een Database Access Object (DAO) en de taak van een DAO IS het afhandelen van communicatie met de database. De taak van Artikel (soort) is het encapsuleren van gegevens over een artikel(soort) en het aanbieden van functies om iets met die gegevens te doen.
Het opzetten van een verbinding met een database en het raadplegen van die database (of welke datasource dan ook) hoort daar niet bij.


Edit: /spuit 11

[ Voor 3% gewijzigd door Kwistnix op 10-03-2006 13:23 ]

[Verwijderd]

Op die manier, er wordt dus een aparte entiteitsklass aangemaakt, die los staat van de klasse met de returnArtikelsoortLijst (e.d.).

Ik geloof dat ik hem vat, ben op het moment Tubby's link ook even aan het doornemen

[Tubby]

In de link is het wel overdreven moeilijk uitgelegd, maar wellicht kan ik het nog meer verduidelijken met de volgende stukjes code

Java:

public class GeneralDao {
    // opent de verbinding met de database en geeft een connection object terug
    protected Connection open() {
        try {
            Class.forName(DatabaseInformation.databaseDriver);
            connection = DriverManager.getConnection(DatabaseInformation.databaseConnection);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        return connection;
    }
    
    // sluit de verbinding met de database
    protected void close(Connection c) {
        try {
            c.close();
        } catch(Exception e) {
            e.printStackTrace();
        }
    } 
    // voert een selectie query uit op de database
    public ResultSet select(String q) {
        Connection c = open();
        try {
            statement = c.createStatement();
            resultset = statement.executeQuery(q);
            
        } catch(Exception e) {
            e.printStackTrace();
        }
        close(c);
        return resultset;
    }
    
    
    // update
    public boolean update(String q) {
        Connection c = open();
         status=false;
        try {
            statement = c.createStatement();
            statement.executeUpdate(q);
             close(c);
             status=true;
        } catch(Exception e) {            
            e.printStackTrace();
        }
        close(c);
        return status;
    }
}

Java:

public class ArtikelsoortDao extends GeneralDao {
    
    public Artikelsoort returnArtikelSoort(int id) {
        Artikelsoort artikelSoort = new Artikelsoort();
               
        try {
           resultset = super.select("SELECT * FROM artikelsoort WHERE soortid = "+ id);
           while (resultset.next()) {
                artikelSoort.setSoortid(resultset.getInt(DatabaseInformation.ARTIKELSOORT_TBL_SOORTID));
                artikelSoort.setNaam(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_NAAM));
                artikelSoort.setVerhuur(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_VERHUUR));
                artikelSoort.setBtw(Integer.parseInt(resultset.getString(DatabaseInformation.ARTIKELSOORT_TBL_BTW)));
           }
        } catch(Exception e) {
            e.printStackTrace();
        }
        return artikelSoort;
    }
}

Java:

// Artikelsoort.java
public class Artikelsoort {
    
    private int soortid;
    private String naam;
    private int btw;
    private String verhuur;
    
    //getters, setters etc
}

Maar gezien je werkwijze vind je het misschien wel interessant om eens naar hibernate te kijken. http://www.hibernate.org
Die doet namelijk precies wat jij wil, een java-object structuur uit een database lezen (en wegschrijven)

[ Voor 106% gewijzigd door Tubby op 10-03-2006 13:37 ]

[Verwijderd]

Ik heb 'em, hartstikke bedankt ben meteen begonnen met schrijven van nieuwe code
Edit:
Hoewel ik nog druk bezig ben java an-sich in de vingers te krijgen, is het misschien nuttig om een boek aan te schaffen over design patterns (we krijgen binnenkort een groot javaproject en het is dus misschien wel handig)?
En heb je misschien aanraders (Engels of Nederlands maakt niet uit)?

[ Voor 70% gewijzigd door Verwijderd op 10-03-2006 13:47 ]

[Tubby]

Heb geen aanraders, heb vanuit school thuis nog wel een boek staan, maar die heb ik alleen voor het SingleTon pattern gebruikt. Ben overigens ook wel geinteresseerd in een goed boek over design patterns voor naslag of eventuele nieuwe patterns. Dus laat maar even weten als je iets gevonden hebt

Verder gebruik ik veel google om meer te weten te komen over de verschillende design patterns en voorbeelden van toepassingen. Op die site van sun kun je de meeste wel vinden en daar staat het allemaal wel uitgelegd, maar met concrete voorbeelden heb je het vaak een stuk sneller door.

[ Voor 23% gewijzigd door Tubby op 10-03-2006 13:56 ]

[Verwijderd]

Ja precies, dat is toch wat meer 'tastbaar', maar goed ik zal de mediatheek op school eens raadplegen, daar staat wel een flink rek met leesvoer

[Kwistnix]

In dit topic staan een aantal goed boeken over (onder andere) design patterns inclusief motivatie van GoT users

[rml][ Alg] Centraal boekentopic - part II[/rml]

Als je eerst meer informatie wil zoeken op het internet dan zijn de design patterns van de 'Gang of Four' (GOF) een goed startpunt.

Eventueel is deze link nog handig:

http://www.hzeeland.nl/~brui0006/dpcd/hires/contfs.htm

[ Voor 42% gewijzigd door Kwistnix op 10-03-2006 14:31 ]

[Verwijderd]

FallenAngel666 schreef op vrijdag 10 maart 2006 @ 14:25:Als je eerst meer informatie wil zoeken op het internet dan zijn de design patterns van de 'Gang of Four' (GOF) een goed startpunt.

Voor de beginnende Java developer? De "head first design patterns" is een goede starter voor design patterns in Java.

[ Voor 3% gewijzigd door Verwijderd op 10-03-2006 19:01 ]

[whoami]

Er staat heel wat boek-informatie in het topic dat FallenAngel666 al vernoemde, dus, als het over boeken gaat, post het dan daar aub.

[Kwistnix]

Verwijderd schreef op vrijdag 10 maart 2006 @ 19:00:
[...]

Voor de beginnende Java developer? De "head first design patterns" is een goede starter voor design patterns in Java.

Er zijn best GoF patterns die goed te begrijpen zijn voor een iemand die niet zo veel van design pattern weet en waar ze ook gelijk toepassingsmogelijkheden voor zijn.
In het DAO voorbeeld kan je bijvoorbeeld de AbstractFactory erbij pakken.
Een Singleton is echt geen moeilijk pattern om te begrijpen en te implementeren, hoewel niet altijd wenselijk en dat kan nog weleens moeilijk in te schaten zijn.
Iedereen heeft wel ooit eens iets met java.io gedaan en dan heb je bijvoorbeeld de Decorator ook al te pakken.

Etc.