Hjelp til å forstå hvordan java henger i "sammen"

[Salvesen.]

Hei,

 

Har java på skolen i år. Det å programmere i Java går helt fint, alle innleveringer går greit da vi får en "oppskrift" og så bare utfører jeg den. Men det jeg virkelig sliter med er å forstå hvorfor ting gjøres på de forskjellige måtene. 

 

Som en oppgave i går der jeg først lagde ett interface, så en abstrakt klasse som implementerer interfacet for så å lage to klasser som arvet fra den abstrakte klassen. alt dette går veldig fint for meg å lage, og jeg skjønner hvordan det brukes om en annen. Men jeg klarer ikke å ta inn over meg hvorfor. Jeg sliter altså med oppbyggningen av java kode, eller objekt orientert kode. 

 

Hadde jeg ikke fått oppgaven på den måten, med step by step instruksjoner hadde jeg lagd den på en helt annen måte, og for å være ærlig en mye lettere måte. Men jeg regner med at denne oppdelingen er nyttig til større prosjekter. 

 

Så er det noen som vet om noen nyttige resurser for å lære seg mer om oppbyggingen av java kode og hvorfor en gjør det? Hva som er fordelene osv. 

 

Jeg føler foreleser dropper mye av dette, forteller mye om hva ett interface er, hva det brukes til osv men aldri hvorfor, og når en skal bruke det og når en bør droppe det osv. 

 

Ble nok noe rotete dette, men håper noen forstår og kan vise meg i rett retning

Endret 19. mars 2016 av Salvesen.

[stelar7]

Oracle Java Documentation:

https://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html

https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html

 

Stack Overflow:

http://stackoverflow.com/questions/1221512/when-to-use-abstract-class-or-interface

http://stackoverflow.com/questions/504904/how-are-java-interfaces-actually-used

http://programmers.stackexchange.com/questions/131332/what-is-the-point-of-an-interface

http://programmers.stackexchange.com/questions/96947/why-should-i-declare-a-class-as-an-abstract-class

http://stackoverflow.com/questions/22085985/why-do-we-need-abstract-classes-in-java

 

Div. Blogger:

http://java67.blogspot.no/2014/02/what-is-actual-use-of-interface-in-java.html

https://dzone.com/articles/programming-when-use

http://www.javacoffeebreak.com/faq/faq0084.html

[henrikwl]

Dette har ikke så veldig mye med Java å gjøre, men har mer generelt med det objektorienterte programmeringsparadigmet å gjøre. Grunnen til at du ikke bare skriver alt "rett fram" (som i prosedyrelle språk som f.eks. C) er at det objektorienterte paradigmet bedre tilnærmer seg den virkelige verden og dermed er lettere å forstå.

 

Se for deg konseptet "Kjøretøy". Vi har vel begge to en ganske så lik oppfatning av hva et "Kjøretøy" er, men det finnes ikke noe slikt som et rent kjøretøy - altså noe som kun er et kjøretøy og ikke kan spesifiseres nærmere. "Kjøretøy" kan dermed sammenlignes med en abstrakt klasse i Java. Den beskriver en type objekt med en del egenskaper, men det gir ingen mening å snakke om noe konkret objekt på det abstraksjonsnivået.

 

"Bil" og "Lastebil" er begge typer av objekter som også kan sies å være av typen "Kjøretøy", og det gir også mening å snakke om konkrete objekter av typen "Bil" og "Lastebil". Trekker vi det inn i Java-verden, kan vi si at Bil og Lastebil begge to arver fra klassen Kjøretøy, men spesifiserer også ekstraegenskaper som skiller dem fra hverandre.

 

Interfacer er Java sin måte å implementere multippel arv på, uten å få med for mange av ulempene ved det. (C++ støtter multippel arv, men jeg går ikke inn på det her). Se for deg Isofix-fester til barnesete i bil. Vi kan si at Bil implementerer Isofix-interfacet. I noen sammenhenger er det ikke så veldig interessant at det er et objekt av typen Bil vi snakker om, vi er kun interessert i det som har med Isofix-festet å gjøre. Dermed kan vi referere til objektet som et Isofix-objekt i stedet for en Bil - det gjør det lettere å forstå hva som skjer i koden.

 

Dette var veldig kort, fryktelig forenklet og med en masse snarveier tatt. Men håper det gir deg en liten idé om hvordan ting henger sammen, og hvor du skal begynne å studere videre for å fylle inn hullene.

[quantum]

Det er ikke så enkelt å se poenget med interfaces og abstrakte klasser i små programmer, som gjerne sånne oppgaver er. 

 

En kan betrakte et interface som en kontrakt, som spesifiserer et minimum av funksjonalitet for at to komponenter/klasser skal kunne samvirke. I større systemer er det viktig at ulike moduler ikke er hardt koblet sammen, da ender systemet etterhvert opp som en kjærringknute som ingen får løst opp i, fordi selv små endringer da forplanter seg og får konsekvenser i hele systemet, og systemet blir umulig å vedlikeholde og videreutvikle.

 

En abstrakt klasse kan man se på som et "halvfabrikat", hvor felles boilerplate-kode er ferdig implementert, og man selv bare skal fylle ut den koden som er spesifikk for det funksjonsområdet man selv implementerer. 

 

Selv om multithreading i bunn og grunn er et komplisert emne, kan du jo likevel ta en titt på Runnable interface, som bare inneholder en metode; void run(); Kravet til run "... is that it may take any action whatsoever. " , altså et ganske åpent krav som sier at du egentlig kan få lov til å gjøre akkurat hva du vil i en separat tråd som du kan i hovedtråden til programmet ditt, den er tross alt bare en tråd den også. Så hvis du nå bare implementerer den koden du ønsker å få eksekvert i en separat tråd, inni metoden run(), sørger Java-runtime, for at du kan få den koden eksekvert i parallell. Det er ikke Runnable-interface i seg selv som får ting til å skje i parallell, men resten har du i utgangspunktet ikke noe som helst behov for å vite noe om (når vi snakker om helt enkle scenarier, ihvertfall). Runnable er bare en kontrakt, eller konvensjon om du vil. MÅTEN multithreadingen er implementert på er irrelevant, og selve pointet her, er at både din implementasjon inni metoden run(), og den tekniske implementasjonen av multithreadingen på den andre siden, kan endres uten å påvirke hverandre, så lenge man ikke bryter kontrakten.

 

Isteden for at alle i java-klassen (skoleklassen altså) sitter hver for seg og løser små mikkemus-oppgaver hver for seg, burde dere heller få i gruppeoppgave å implementere deler av et større program hver for dere, hvor det på forhånd er definert noen interfaces som forteller hvordan delene til slutt skal kobles sammen til et fungerende program. Isolert sett er interfaces helt "meningsløse", så jeg synes ikke det er så merkelig at det er vanskelig å forstå poenget med dem, hvis dere ikke har noen reell nytte av dem i oppgavene dere får.

[Enthroner]

Jeg vil tro at samen rett og slett bare har en pose med java bundet til seg med hyssing.