Hergebruik en afscherming.
Verder lijkt het me handig voor je om een eens een leuke lap tekst te lezen over packages etc.
Verder lijkt het me handig voor je om een eens een leuke lap tekst te lezen over packages etc.
{signature}
Bij kleine applicaties heb je er minder snel last van, maar je kan nagaan hoe lastig je systeem is om te onderhouden als je 1000+ sourcefiles in dezelfde directory hebt staan.
http://java.sun.com/docs/...a/interpack/packages.html
Verder is er geen nut als jij je 3 class brouwseltjes in packages gaat stoppen, maar wel als een ander ze ook gaat gebruiken.
Verder is er geen nut als jij je 3 class brouwseltjes in packages gaat stoppen, maar wel als een ander ze ook gaat gebruiken.
Ons projectje (worms, een tof spel, in jave) werd ook ingedeeld in packages. Wij gebruikten drie hoofdpackages:
één voor de bewerkingen met data, in en uitlezen van bestanden enz, ook de voorstelling hiervan.
één voor de game-engine
één voor het grafische gedeelte
Dit was volgens ons een logische indeling. Het datagedeelte kunnen we trouwens voor een ander projectje hergebruiken :-)
één voor de bewerkingen met data, in en uitlezen van bestanden enz, ook de voorstelling hiervan.
één voor de game-engine
één voor het grafische gedeelte
Dit was volgens ons een logische indeling. Het datagedeelte kunnen we trouwens voor een ander projectje hergebruiken :-)
Om te garanderen dat packages niet afhankelijk van elkaar kunnen zien, zet ik ze ook vaak in verschillende source directories. Hierdoor kan ik bij het compilen garanderen dat een model niet afhankelijk is van een view, maar een view natuurlijk wel weer van de model.
Uiteraard doe ik het compileren en builden mbv ANT omdat je anders veel te veel onhandige acties moet uitvoeren.
Uiteraard doe ik het compileren en builden mbv ANT omdat je anders veel te veel onhandige acties moet uitvoeren.
[ Voor 18% gewijzigd door Alarmnummer op 06-01-2004 15:45 ]
Klik maar eens hier:
http://java.sun.com/j2se/1.4.2/docs/api/
En probeer je dan eens voor te stellen dat alle classes in dezelfde namespace zitten (m.a.w. zie de frame linksonder). Dan wordt je toch gek of niet
Packages zorgen ervoor dat je je types hierarchisch kan ordenen (en bovendien heb je ook nog zoiets als package visibility: classes binnen dezelfde package kunnen wel bij elkaars members, maar classes daarbuiten niet)
En, als je kijkt naar hoe vaak het woord Policy in verschillende contexten wordt gebruikt: zonder packages had je ze allemaal een andere naam moeten geven...
http://java.sun.com/j2se/1.4.2/docs/api/
En probeer je dan eens voor te stellen dat alle classes in dezelfde namespace zitten (m.a.w. zie de frame linksonder). Dan wordt je toch gek of niet
Packages zorgen ervoor dat je je types hierarchisch kan ordenen (en bovendien heb je ook nog zoiets als package visibility: classes binnen dezelfde package kunnen wel bij elkaars members, maar classes daarbuiten niet)
En, als je kijkt naar hoe vaak het woord Policy in verschillende contexten wordt gebruikt: zonder packages had je ze allemaal een andere naam moeten geven...
Ik wilde net gaan vragen of je al eens naar de 'compileWithWalls' ant task had gekeken, maar je gebruikt het blijkbaar alAlarmnummer schreef op 06 januari 2004 @ 15:45:
Om te garanderen dat packages niet afhankelijk van elkaar kunnen zien, zet ik ze ook vaak in verschillende source directories. Hierdoor kan ik bij het compilen garanderen dat een model niet afhankelijk is van een view, maar een view natuurlijk wel weer van de model.
Uiteraard doe ik het compileren en builden mbv ANT omdat je anders veel te veel onhandige acties moet uitvoeren.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Pagina: 1