Lage et bibliotek som inkluderer HashMap, ArrayLists, flere classes m.m.

[logikeren02]

Hei!

La oss si at jeg skulle ønske å lage meg et slags 'vennenettverk' med oversikt over hvem som eier bøker, hvem som låner PS4-spill av hverandre og 'slikt' - hvordan burde jeg da gå frem.

 

Sett at jeg starter med tre classes - Hoved(av mangel på bedre navn), Personer og Spill vil jeg anta at jeg har et greit utgangspunkt. Jeg har mer eller mindre bestemt meg for at personene skal lagres i en arraylist, mens jeg "vil" bruke HashMap på PS4-spillene.

 

Jeg ønsker å ha en form for meny i Hoved.java-filen, hvor brukeren kan legge til personer, legge til kjøpte bøker, sette inn hvem som eventuelt låner ei bok, en oversikt over hvem som eier hva, og eventuelt hvem som låner hvilket spill.

 

Jeg antar at det skal en god del metoder inn i classene, spesielt da spill.java og personer.java. Det vil kanskje være logisk å ha en getPersoner og setPersoner? I tillegg til getSpill og setSpill?

 

Meningen er ikke at dette skal bli noen store greier, men bare en liten oversikt jeg/vi kan bruke slik at spillene ikke blir borte.

 

All hjelp settes stoooooooor pris på!

[quantum]

Har du tenkt noe på lagring her? Hvis informasjonen skal "overleve" når programmet ditt avsluttes må det hele uansett lagres på et eller annet vis. Enten kan det lagres på en "flat fil", eller i en database.

 

Hva er argumentene dine for å lagre personer i en List og spillene i en Map? Det er ingen andre som kan svare deg på hva som er riktig uten at du forklarer hvordan og hvorfor du har tenkt å bruke disse datastrukturene.

 

For å få orden på tankene kan det også være lurt å sette seg ned og skrive ned hvilke funksjoner du skal ha, feks.

 

1) registrere person

2) registrere spill på person

4) låne bort et registrert spill til annen person

5) levere tilbake lånt spill

6) slette person og alle spillene (? eller skal låner da få overta utlånte spill?)

7) slette spill (som ikke er utlånt)

8) ...

 

Du er også litt inne på hvordan du vil strukturere programmet ditt. Du har en klasse som du bare kaller "Hoved" som kanskje kan "forstå" kommandoer fra brukeren og sende dem til en eller flere andre klasser som kan utføre de ulike kommandoene ved å kalle ulike metoder på domeneobjektene Person og Spill. Disse inneholder navn på person og spill, hvilke spille en person eier og låner, og også metodene som legger inn og fjerner spill fra de ulike listene/map'ene: f.eks. List<Spill> ownedGames, borrowedGames<Spill> i Person. Til slutt kan du eventuelt ha kode for persistens. Dette kan ligge i egne klasser som tar seg av database eller fil-operasjoner uten at resten av programmet trenger bry seg med hvordan det gjøres.

[logikeren02]

Hei. Har vel tenkt å bruke printwriter for å lagre de i en tekstfil. Ikke noe særlig mer komplisert enn det. Det å få lest inn filen igjen bør ikke by på store problemer.

 

Jeg sliter veldig med hva slags metoder jeg skal legge i de forskjellige klassene. Jeg klarer liksom ikke å se det helt for meg =(

[Lock-Aze]

Vel, det første du må "se for deg" er hva skal man gjøre med de forskjellige klassene. F.eks person, hva skal ligge i klassen person? Bare navn f.eks? Så i klassen film, navn på spill? Hvem eier det? Skal det kunne lånes ut? Etc. Det første du må gjøre er å finne ut: hva skal programmet gjøre, deretter finne ut hvordan det skal gjøre det.

[Karl Skapeland]

Hei. Har vel tenkt å bruke printwriter for å lagre de i en tekstfil. Ikke noe særlig mer komplisert enn det. Det å få lest inn filen igjen bør ikke by på store problemer.

 

Jeg sliter veldig med hva slags metoder jeg skal legge i de forskjellige klassene. Jeg klarer liksom ikke å se det helt for meg =(

 

Apropos lagring - du kan jo heller serialisere hele objektstrukturen til JSON, evt XML. Til JSON kan du bruke f.eks. Google Gson og til XML kan du bruke f.eks. XStream. Det gjør det iallefall enkelt å lese det inn igjen.

[scav-]

Ikke bruk XML eller JSON, det er elendige formater for å lagre data. En ren tekstfil er faktisk raskere.

 

Om du ikke vil bruke en relasjonsdatabase (hvem ønsker egentlig å bruke en slik), kan jeg anbefale at du lagrer data til disk ved å serialisere en "data store" du selv kan lage fort. Bruker du https://github.com/EsotericSoftware/kryo til dette, vil den både være rask å "spole" opp når du starter, og skrive når du lukker ned.

 

Jeg tror det hadde vært enda kulere om du vurderte å lagre data etter event sourcing prinsippet her, men event sourcing er kanskje litt abstrakt om en bare driver å eksperimenterer.

 

Forøvrig vil jeg bare legge til at en ArrayList er ment å dekke nesten alle behov, og at det bare unntaksvis er andre klasser du bør bruke i The Collections Framework. Siden du uansett bør bruke List<T> på alle lister, kan du bytte ut klassen som backer List<T> dersom det skulle vise seg at du har utvidede behov, f.eks. om du velger å bruke threads eller skal ha en bucket for unike objekter i listen.

 

Når det kommer til klassene dine, anbefaler jeg at du tenker på domenet du jobber under. Du kan ha klasser som Person for kompiser, så kan du bruke abstrakte klasser på implementasjoner som BorrowedItem.class (siden du har en konseptuell ide om hva en ting du låner er, men den ikke faktisk eksisterer, er dette et bra utgangspunkt).

 

BorrowedItemPS4Game extends BorrowedItem er et eksempel. Fordelen her er at du kan lagre alle BorrowedItem i samme listen, og finne f.eks alle PS4 spill ved å kjøre instanceof BorrowedItemPS4Game.

 

Dette er i alle fall mine umiddelbare tanker, og du behøver ikke bruke noe av det, men håper det i alle fall inspirerer. Det viktigste er å bare kode i vei og ikke ta det så høytidelig om alt du gjør er rett eller feil.

[Karl Skapeland]

Ikke bruk XML eller JSON, det er elendige formater for å lagre data. En ren tekstfil er faktisk raskere.

Kan du utdype din påstand om at XML / JSON er elendige dataformater?

 

Jeg kan innrømme at de ikke er ideelle i enhver sammenheng, men i trådstarters tilfelle kan det faktisk være greit å ha noe som lagrer datastrukturen enkelt og greit, så vedkommende slipper å skrive masse kjedelig boilerplate i en tidlig fase.

[Karl Skapeland]

Ikke bruk XML eller JSON, det er elendige formater for å lagre data. En ren tekstfil er faktisk raskere.

Kan du utdype din påstand om at XML / JSON er elendige formater å lagre data i? Trådstarter har sikkert ikke til hensikt å serialisere/deserialisere flere terabytes med data.

 

Jeg kan innrømme at de ikke er ideelle i enhver sammenheng, men i trådstarters tilfelle kan det faktisk være greit å ha noe som lagrer datastrukturen enkelt og greit, så vedkommende slipper å skrive masse kjedelig boilerplate i en tidlig fase

Endret 6. november 2014 av Karl Skapeland

[quantum]

 

Om du ikke vil bruke en relasjonsdatabase (hvem ønsker egentlig å bruke en slik), kan

 

de som bryr seg om dataene sine kanskje? konsistens og sånn? just a wild guess ...

Endret 8. november 2014 av quantum

[quantum]

 

Ikke bruk XML eller JSON, det er elendige formater for å lagre data. En ren tekstfil er faktisk raskere.

Kan du utdype din påstand om at XML / JSON er elendige formater å lagre data i? Trådstarter har sikkert ikke til hensikt å serialisere/deserialisere flere terabytes med data.

 

 

Det er kanskje mest et spørsmål om hvilken teknologi man ønsker å lære seg her ...

[scav-]

 

 

Om du ikke vil bruke en relasjonsdatabase (hvem ønsker egentlig å bruke en slik), kan

 

de som bryr seg om dataene sine kanskje? konsistens og sånn? just a wild guess ...

 

Det finnes bedre måter, du kan f.eks. bruke Akka Persistence og lage en event store. Ikke bare får du konsistens, du har også en komplett logg av hver eneste lille ting i hele datasettet ditt. Det er bare idiotisk å drive og slette og sette inn nye data (det er i prinsippet dette en insert eller update gjør). CRUD kaste bort masse kontekst og gir deg ingen merverdi av data i form av "hvordan kom vi her til" og "hvilke state var systemet i da det krasjet".

 

Selvsagt bruker de fleste relasjons-databaser i dag, men det betyr ikke at en modell ala event sourcing ikke er overlegen.

[scav-]

 

Ikke bruk XML eller JSON, det er elendige formater for å lagre data. En ren tekstfil er faktisk raskere.

Kan du utdype din påstand om at XML / JSON er elendige formater å lagre data i? Trådstarter har sikkert ikke til hensikt å serialisere/deserialisere flere terabytes med data.

 

Jeg kan innrømme at de ikke er ideelle i enhver sammenheng, men i trådstarters tilfelle kan det faktisk være greit å ha noe som lagrer datastrukturen enkelt og greit, så vedkommende slipper å skrive masse kjedelig boilerplate i en tidlig fase

 

Trådstarter kan lagre en hel samling, enkelt og greit. Å lagre data i JSON er tregt og dersom boiler plate er det du forsøker å unngå er XML i alle fall et grusomt valg.

[quantum]

Det finnes bedre måter, du kan f.eks. bruke Akka Persistence og lage en event store. Ikke bare får du konsistens, du har også en komplett logg av hver eneste lille ting i hele datasettet ditt. Det er bare idiotisk å drive og slette og sette inn nye data (det er i prinsippet dette en insert eller update gjør). CRUD kaste bort masse kontekst og gir deg ingen merverdi av data i form av "hvordan kom vi her til" og "hvilke state var systemet i da det krasjet".

 

 

 

 

 

Selvsagt bruker de fleste relasjons-databaser i dag, men det betyr ikke at en modell ala event sourcing ikke er overlegen.

 

 

Akka Persistence betegner seg selv som "eksperimentelt", så det er sikkert fint å eksperimentere med :o) Det at de fleste bruker relasjons-databaser betyr som du sier ikke at event sourcing ikke er overlegent. Det betyr heller ikke at det ér overlegent. Så akkurat hva den kommentaren skal tjene til får bare henge i lufta. Ihvertfall inntil noen kommer og forklarer hva man ønsker å oppnå ... før det skjer er spørsmålet litt meningsløst.

 

Noe av pointet med relasjonsdatabaser er forøvrig at man skal kunne finne nøyaktig fram til siste konsistente tilstand etter en krasj. Hvordan man kom dit kan man også finne ut av om man har satt av nok plass til transaksjonsloggen, men det gjør man sjelden av praktiske årsaker. Isteden holder man gjerne styr på det man har interesse av å vite noe om historikken til i audit-log-tabeller, og hvor elegant man synes dét er kan man jo diskutere.

 

I en praktisk verden ville jeg lurt på hvordan event sourcing løser problemet med replay av alle eventene v. oppstart. Blir ikke det fryktelig treigt etterhvert? Med relasjonsdatabaser er det slik at de ikke egner seg til alt, og da opplever man at det blir "fryktelig treigt etterhvert". Kan ingenting om Akka eller Akka Persistence, så kast gjerne litt lys her

 

Hvordan løser event-sorucing behovet for atomære operasjoner? Hvordan vet jeg at systemet er i en konsistent tilstand når alle eventene er lest opp? Transaksjoner?

Endret 10. november 2014 av quantum

[Lock-Aze]

Hvis du skal lagre dette, så kan du jo bare velge flatfil, det enkleste ville nok vært å bare brukt en standard SQL base, for så å bruke java sin SQL implementasjon. (Men det er sikkert fordi jeg har gjort det ett par ganger og sett at det er en enkel måte å gjøre det på)

 

Det du i praksis kan sette opp er en SQL base der du har person, med f.eks personID som pk, film, med filmID som pk, og spill med spillID som pk, så lager du f.eks personSpill som inneholder personID og spillID som fk's og personFilm som har personID og filmID som fk's, så skal det være ganske enkle spørringer å joine disse tabellene.

 

Men, det er mange måter å løse dette på.