Dilemma om typevalg

[B3nd1k]

Heisann!

 

Jeg sitter å utvikler et lite program for meg selv som skal brukes til timeregistrering. Prosjektet er både for å ha noe konstruktivt å gjøre etter jobb nå om sommeren, og for å utvikle min horisont litt videre.

 

Jeg har en modell-klasse for et skift (en "jobbvakt" altså). Klassen har variabler for blant annet dato, når vakten startet og når vakten sluttet. Typiske verdier er altså 08:00 for start og 16:00 for slutt. Jeg har til nå brukt en kjappløsning med java.sql.Date og java.sql.DateTime for disse variablene, siden alt uansett hentes ut fra en database hvor dette er lagret som date og time. Jeg håper det ble sånn smått forståelig.

 

Jeg går litt fram og tilbake med tanke på hvordan jeg skal lagre disse verdiene. Jeg har så langt vært fornøyd med å ha det slik, men jeg er usikker på hvor godt valget egentlig er. DateTime har så vidt jeg har forstått også mulighet til å lagre dato, noe som blir litt overkill med tanke på den egne variabelen jeg har for dato. Samtidig gir det meg muligheten til å bruke klassen SimpleDateFormat for å enkelt forandre på formatet.

 

Jeg har vært innom en rekke løsninger; bruke en integer for å lagre sekunder siden 00:00, lage en egen klasse med variabler for time, minutt og sekunder siden 00:00, og en del andre mindreverdige løsninger. Problemet er i hovedsak at jeg trenger muligheten til å vise tiden i forskjellige formater alt etter hvilken situasjon jeg er i og at jeg må kunne regne på tidsforskjeller for å finne lengden på en vakt.

 

For å summere opp litt er jeg usikker på valget av variabeltype for to variabler som i all hovedsak skal holde på to forskjellige tidspunkter. Valget må gjøre at regning blir nogen lunde enkelt, samtidig som at jeg må kunne formatere tidspunktene på den måten jeg vil.

[loathsome]

http://no2.php.net/time

 

Da får du også full fleksibilitet.

[B3nd1k]

http://no2.php.net/time

 

Da får du også full fleksibilitet.

Merkelig nok postet jeg i Java-forumet av den enkle grunn at jeg programmerer dette i Java PHP er ikke noe alternativ i dette tilfellet, som sagt gjør det jeg dette for å øke min forståelse og kunnskap om språket.

[loathsome]

Jeg merket nettopp at jeg hadde svart i feil delforum selv, beklager dette Til mitt forsvar var klokken 7 om morgenen

[___]

I de fleste tilfeller der jeg skal holde rede på et tidspunkt, benytter jeg java.util.Date.

 

Denne klassen har metoden getTime() som returnerer antall millisekunder siden 1.1.1970, bedre kjent som "unix time". Det er rimelig enkelt å utføre kalkulasjoner på disse verdiene.

 

Ellers vil jeg anbefale Joda Time, som er et java-library som har endel kjekke funksjoner du sikkert vil kunne få bruk for:

 

http://www.joda.org/

 

Werner

[nirolo]

Enig med wernie at java.util.Date er det naturligste å bruke i applikasjonen. Når du lagrer den i databasen så er det antagelig greiest å lagre den som en Dato der også. Det er riktignok en del databaser som har litt frynsete datohåndtering. Da kan du bruke date.getTime() og lagre den som et heltall i stedet. Ulempen er jo selvfølgelig at du må konvertere fram og tilbake hele tiden, samt at det ikke er like lett å se i databasen hva som er blitt lagret (ved debugging ol).

[B3nd1k]

Det ble kanskje litt uklart i den første posten, men selve datoen lagrer jeg som en date i databasen. De to tidspunktene for når jeg starter og når jeg slutter lagres dog som time. Jeg henter disse ut og lagrer dem som java.sql.Date og java.sql.Time, og oppretter et objekt som inneholder disse. Til nå har jeg lagret dem som java.sql.Date/Time i objektet også, men jeg lurer på om jeg skal gå over til å bruke java.util.Date for både dato og tidspunkt i objektet.

 

Uansett, det virker på dere som om at java.util.Date er det som gjelder, både for datoer og tidspunkt. Og når jeg tenker meg om blir kanskje dette det enkleste med tanke på muligheten til å formatere, og muligheten til å regne enkelt ved hjelp av getTime().

 

For å være ærlig har jeg mer eller mindre angst mot å bruke libraries, i alle fall i applikasjoner jeg selv skal utvikle. Jeg føler at det er litt "juks", hvis du skjønner hva jeg mener

 

Takk for hjelpen begge to!

[___]

Bare som et tips... Hvis applikasjonen din skal kunne lagre til en database, så bør du titte på JPA. JPA (Java Persistence API) benyttes i EJB 3.0 standarden for å mappe Java-klasser mot databaser. Det fine med JPA er at det ikke er forbeholdt applikasjoner som skal kjøre i en applikasjonsserver (JEE) men kan likegodt brukes i standard (J2SE) Java-applikasjoner.

 

Som eksempel på en mapping av dato+klokkeslett i JPA:

 

  @Column(name="MESSAGE_ENTERED", nullable=false)
 @Temporal (TemporalType.TIMESTAMP)
 private Date messageEntered;

 

Selv bruker jeg Hibernate sin implementasjon av JPA. Hvis du er interessert i noe eksempelkode er det bare å si ifra.

 

Det kjekke med JPA er at du slipper å tenke på SQL-syntax og "CREATE TABLE" statements, da databasen opprettes automatisk basert domenemodellen din. Hvilken database du skal jobbe mot, og login-credentials spesifiserer du enkelt i XML-config.

 

I eksempelet over ser du JPA-annotations for å mappe feltet messageEntered til databasefeltet "MESSAGE_ENTERED". Annotasjonen @TemporalType.TIMESTAMP forteller at jeg skal lagre dato+klokkeslett. I tillegg til denne finnes @TemporalType.DATE (kun dato) og @TemporalType.TIME (kun tidspunkt)

 

Noen vil si at det er overkill å bruke Hibernate / JPA i et mindre prosjekt, men jeg vil basert på egen erfaring si at intet prosjekt er for lite. Har man behov for å lagre data i en database, er det faktisk utrolig befriende å slippe å vite noe som helst om databasen man skal jobbe mot, og ikke minst slippe å skrive JDBC-kode.

 

Werner

[B3nd1k]

Applikasjonen må nok ha muligheten til å lagre til databasen etter hvert ja, men akkurat nå er jeg veldig inne i hvordan jeg skal presentere data for brukeren. Jeg har lagt stor vekt på å lage alt så modulært og objektorientert som mulig slik at eventuelle forandringer senere skal bli så enkelt som mulig.

 

Hibernate så virkelig ikke så dumt ut, jeg skal lese litt mer på dette før jeg kommer så langt at jeg skal lage muligheter for å lagre data i databasen! Akkurat nå er jeg veldig inne i presentasjon, og kommer nok til å holde på med akkurat det en stund

 

Takk for tipset!

Endret 19. juli 2008 av B3nd1k

[pgdx]

Hei. Du bør bruke java.util.Date i objektet, men skal du gjøre matematikk med det, må du hive det midlertidig over i en Calendar.

		Date to = new Date();
	Date from = new Date();

	Calendar calFrom = new GregorianCalendar();
	calFrom.setTime(from);

	Calendar calTo = new GregorianCalendar();
	calTo.setTime(to);

	int hours = calTo.get(Calendar.HOUR) - calFrom.get(Calendar.HOUR);

 

Hvis du skriver dette programmet for å lære deg mest mulig, anbefaler jeg at du ikke velger hibernate eller andre JPA-ting, men skriver alt selv.

[blackbrrd]

Jeg hadde brukt dato med klokkeslett i begge variablene. Tenk hvis noen skulle finne på å jobbe fra kl 22 en dag til 06 dagen etterpå!

 

Jeg ser ikke noen grunn til å ikke benytte JPA hvis du vil lære mest mulig. JPA/EQL/HQL fungerer fint å bruke sammen med helt vanlig SQL.

 

Jeg hadde definitivt sett på wernie sitt forslag om JODA. Dato-håndteringsbibliotekene som følger med java er mildt sagt mangelfulle.

[B3nd1k]

Jeg bruker nå java.util.Date, og det fungerer i grunn smertefritt. Kalkulering av antall timer gjør jeg med getTime() og litt divisjon for å få det fra millisekunder til timer. Det fungerer i grunn ganske greit

 

Jeg har merket at tid-bibliotekene er ganske mangelfulle ja. I tillegg synes jeg de er litt merkelig bygget opp, med tanke på de ufattelig mange metodene som er deprecated i java.util.Date.

Jeg har lyst til å holde meg unna biblioteker så lenge som mulig. Kall meg dum og sta, men jeg føler i grunn at jeg jukser hvis jeg bruker det, hehe.

[pgdx]

Jeg har merket at tid-bibliotekene er ganske mangelfulle ja. I tillegg synes jeg de er litt merkelig bygget opp, med tanke på de ufattelig mange metodene som er deprecated i java.util.Date.

Jeg har lyst til å holde meg unna biblioteker så lenge som mulig. Kall meg dum og sta, men jeg føler i grunn at jeg jukser hvis jeg bruker det, hehe.

Men jeg viste jo til Calendar.

 

Og mtp. det å holde seg unna biblioteker; hva er det egentlig du prøver å lære deg?

[B3nd1k]

Men jeg viste jo til Calendar.

 

Og mtp. det å holde seg unna biblioteker; hva er det egentlig du prøver å lære deg?

Jeg er klar over Calendar, men jeg ser i grunn ikke noe poeng i å bruke Calendar der det fungerer uten. Jeg bruker det enkelte plasser, men å regne ut tidsforskjell var i grunn ganske enkelt uten å bruke Calendar. Jeg skal dog se litt mer på det, jeg innså nettopp at det kan bytte ut java.util.Date hvis jeg bare skal bruke variabelen til en dato.

 

Jeg uttrykte meg kanskje litt feil angående biblioteker. Det jeg vil unngå er å bruke bibliotek til alt mulig rart, uten å egentlig behøve det. Jeg er den typen som liker å skrive egne klasser og bibliotek jeg kan bruke istedet for å bruke ferdglagede. Dersom jeg vet sånn halvveis hvordan jeg løse et problem gjør jeg det heller selv istedet for å bruke et ferdig bibliotek. Java er allerede simplifisert nok etter min mening (Nei, det var ikke negativt ment )

 

Men selvsagt, enkelte ting bruker jeg bibliotek til. Eksempler har vært xml-parsing, lydavspilling/lydmanipulasjon og bildebehandling.

[pgdx]

Jeg uttrykte meg kanskje litt feil angående biblioteker. Det jeg vil unngå er å bruke bibliotek til alt mulig rart, uten å egentlig behøve det. Jeg er den typen som liker å skrive egne klasser og bibliotek jeg kan bruke istedet for å bruke ferdglagede.

Da kan du lage din egen datoklasse som er en wrapper rundt Date og Calendar som bare har de nødvendige metodene du trenger. Og ikke bruk metoder som er deprecated. Det er temmelig enkelt å hoppe fra Calendar til Date og back-again.

[blackbrrd]

Problemet man gjerne støter på hvis man lager noe eget istedetfor å bruke noe ferdiglagd, er at du f.eks nå trenger 3 funksjoner. Du begynner da på ditt eget dato-bibliotek. Det tok deg 1 time å fikse. Så viser det seg senere at du trenger et par (mer avanserte funksjoner) som tar deg 4 timer å lage. Så støter du borti et avansert problem (ja, datoer er et helvete), som tar deg 4 dager å fikse.

 

Alternativet er å bruke et ferdiglagd dato-bibliotek som det nevnt ovenfor. Det tar sikkert en time å installere og sette seg inn i. I utgangspunktet har du ikke noen gevinst i forhold til å lage ditt eget, men på lengre sikt så har du spart masse tid - hvis du har funnet et bra bibliotek vel å merke.

 

Jeg kan love deg at evt arbeidsgiver heller vil at du skal bruke et bibliotek som er ferdiglagd istedetfor å implementere ditt eget. Det tar rett og slett for lang tid hvis du skal finne opp hjulet på nytt hver gang.

Endret 22. juli 2008 av blackbrrd

[pgdx]

Jeg kan love deg at evt arbeidsgiver heller vil at du skal bruke et bibliotek som er ferdiglagd istedetfor å implementere ditt eget. Det tar rett og slett for lang tid hvis du skal finne opp hjulet på nytt hver gang.

Oi, da. Det var en «bold statement». Tenk på lisensieringen.

[blackbrrd]

Ja, tenk på lisensieringen. Den Postgresql bruker er fin

 

http://nn.wikipedia.org/wiki/BSD

... BSD-lisensane, noko som tillèt dei som vil bruka kjeldekoden å gjera om lag kva dei vil, derimellom å lukka kjeldekoden til produkta som baserer seg på den lånte koden. ...

Endret 22. juli 2008 av blackbrrd

[pgdx]

Ikke for å komme inn på den diskusjonen, men, ja, BSD-lisensen er fin for brukerne av den. GPL er fin for forfatterne.

[B3nd1k]

Misforstå meg rett nå folkens. Jeg er ikke imot bruk av bibliotek, overhodet ikke. Det jeg heller er imot er å hoppe rett på bruk av bibliotek uten å kunne nok selv først. Jeg føler ikke at jeg har gjort ting som dette mange nok ganger til at jeg kan forsvare det å hoppe rett på bibliotek skrevet av andre. Dersom jeg hadde vært hundre prosent sikker på hvordan jeg skulle utvikle dette hadde jeg ikke hatt noe imot å se på mer avanserte biblioteker skrevet av andre

 

@pgdx: neida, metoder som er deprecated bruker jeg ikke. Det er tross alt en grunn til at de er deprecated Hadde det vært opp til meg hadde så gamle deprecated metoder vært fjernet (deprecated siden 1.1 så vidt jeg husker) for å tvinge folk bort fra dårlige vaner.

Jeg innrømmer at forskjellen på Date og Calendar forvirret meg en god del i begynnelsen, men etter at jeg kom inn i det ble det mer logisk.

Å skrive wrapperklasser var faktisk noe jeg allerede var på vei til å gjøre før jeg kom på å spørre her. Det var en løsning jeg hadde lyst til å unngå hvis det fantes noe enklere, for å si det slik.