Archief - Project Java

Hey iedereen,

We moeten voor school een eigen project maken. Ik heb al een idee en ben er al reeds aan begonnen maar zit op bepaalde vlakken vast.

Mijn ideetje is dus om een prog te maken dat de Magazijn inhoud weergeeft van 'n bedrijf. De bedoeling is dus dat de magazijnchef via invoer artikels kan invoeren (deze moeten in 'n arraylijst komen) en ook nog andere gegevens ( Hoeveelheid...)

Maar ik weet niet goed hoe ik die invoer (van magazijnchef) en array moet koppelen. Al de artikels moeten dus in 'n lijst komen.

Je moet ook artikels dat er in staan kunnen verwijderen , maar dat weet ik totaal niet.

Alvast bedankt!

Heb je een UML klasse diagramma?

een bewijs dat vele cursussen op niet veel trekken ...

men vraagt je een project te maken, maar ze hebben je nog niet geleerd wat een list object is of wat het kan ?

Opbouwende kritiek bestaat niet op dit deel van het forum.
Vroeger niet, nu niet. Jammer

Neen ik heb nog geen UML klassediagram gemaakt..

En idd ze hebben ons nog niets geleerd over een list object of dergelijke..

Lang leve "Hoge"school ..

Dus je vraag is eigenlijk hoe je met een ArrayList moet werken, los van het feit hoe je deze moet implementeren bij je Magazijn oefening? Ifnot: meer info posten.

Is het niet gemakkelijker om met een Map te werken in plaats van met een ArrayList. Elk artikel is toch normaal gezien uniek. Lijkt me ook handiger om dan een Artikel op te zoeken.

Nu hetgeen ik lees zal het wel zo iets zijn.

In de klasse waar je je artikels bijhoudt:

Dan de klasse Artikel:

Maar gezien een artikelnaam uniek is kan je het ook met een map doen (wat mij gemakkelijker lijkt om dan een artikel op te zoeken), dan wordt het:

De string is dan de key, in ons geval de naam van het artikel. Om dan een artikel toe te voegen of op te vragen:


Veel handiger via Map in dit geval. Bij die ArrayList zou je dan al de index moeten weten of hem mogen beginnen overlopen, naam van het artikel opvragen en kijken of het overeenkomt met hetgeen jij vroeg.

Trouwens, eerst je ontwerp maken en dan pas beginnen programmeren :naughty:

Karre zei:

Code:

List<Artikel> deArtikels = new Arraylist();

Klik om te vergroten...

Nu we het toch over een ArrayList hebben, is er een reden waarom deze vaak als volgt gemaakt wordt:
List<G> list = new ArrayList<G>();

ipv

ArrayList<G> list = new ArrayList<G>();

Want eens gekozen voor een ArrayList blijf je toch bij een ArrayList en win je toch niets door te zeggen dat hij een List is?

Fraggie zei:

Want eens gekozen voor een ArrayList blijf je toch bij een ArrayList en win je toch niets door te zeggen dat hij een List is?

Klik om te vergroten...

Je wint aan flexibiliteit (en je moet minder typen).

Wat als je nu toch vaststelt dat een LinkedList in dit geval beter presteert? Als je tegen de List interface programmeert, vervang je gewoon new ArrayList door new LinkedList en ben je zeker dat je aan de rest van de code niets hoeft te wijzigen.

Programmeren tegen een interface in plaats van tegen een concrete implementatie is sowieso een goede gewoonte, maar ik wil wel toegeven dat het voordeel binnen de grenzen van een method waarschijnlijk minder significant is. Tussen klassen daarentegen: interfaces all the way.

Fraggie zei:

Nu we het toch over een ArrayList hebben, is er een reden waarom deze vaak als volgt gemaakt wordt:
List<G> list = new ArrayList<G>();

ipv

ArrayList<G> list = new ArrayList<G>();

Want eens gekozen voor een ArrayList blijf je toch bij een ArrayList en win je toch niets door te zeggen dat hij een List is?

Klik om te vergroten...

Dit wordt omschreven als 'programming to an interface, not to an implementation'. Als je hierop gaat google'n zal je al veel nuttige informatie vinden die het beter zal uitleggen dan ik het kan ;-)

Komt er (kort en ruw gezegd!) op neer dat je interface (List) in dit geval een bepaald contract aanbiedt. Bijvoorbeeld, het ophalen van een element op een bepaalde index: get(index). Dat dit gebeurt door het element op te zoeken in een array (ArrayList) of in een gelinkte lijst (LinkedList) maakt voor jou in principe niet uit - het correct functioneren van de rest van je programma zou hier niet op mogen steunen! Dat zorgt er ook voor dat je je implementatie makkelijk kan aanpassen. Stel dat Oracle in de volgende versie van Java met een hyper-efficiënte AwesomeList uitkomt, moet je je code op welgeteld één plek aanpassen in plaats van overal, en omdat je enkel het contract gebruikt ben je zeker dat deze 100% correct blijft werken*.

Dit is een beetje een 'gemaakt' voorbeeld en een onrealistische situatie, maar het komt er op neer dat een concrete implementatie niet van belang zou mogen zijn, wel het contract - de interface. Een meer realistisch voorbeeld van het vervangen van de implementatie maar behouden van het contract is bij het testen. Als je wil gaan unit testen wil je niet dat het testen van een bepaalde service faalt omdat de database niet bereikbaar is (dat is immers meer integration testing, niet unit testing - je wil ENKEL je service testen, niet je databank-connectie). Dus zal je de implementatie van je 'haal-mijn-gegevens-uit-de-databank' object vervangen door een een andere implementatie - eentje met hardcoded gegevens bijvoorbeeld, die niet kan falen. Als je contract hetzelfde blijft, moet je niets veranderen in je code.

* Let op: het contract is niet in alle gevallen even sterk. De methode 'add' van de Set interface is bijvoorbeeld niet 'verplicht' - het is toegelaten dat implementaties van de Set interface gewoon een exception gooien als deze wordt opgeroepen.

Gek want program to an interface, not an implementation kende ik, maar zou ik nooit associëren met een datastructuur. Desalniettemin hebben jullie duidelijk aangetoond dat dit toch ruim toepasbaar is:

forloRn_ zei:

Wat als je nu toch vaststelt dat een LinkedList in dit geval beter presteert?

Klik om te vergroten...

JensDT42 zei:

Stel dat Oracle in de volgende versie van Java met een hyper-efficiënte AwesomeList uitkomt, moet je je code op welgeteld één plek aanpassen in plaats van overal, en omdat je enkel het contract gebruikt ben je zeker dat deze 100% correct blijft werken*.

Klik om te vergroten...

Merci voor info.