Generel Java

Jeg har lige læst http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?

Og har derfor opdaget, at der er nogle områder, som jeg er usikker på!

Q: In Java, under what circumstances would you use abstract classes instead of interfaces? When you declare a method as abstract, can other nonabstract methods access it? In general, could you explain what abstract classes are and when you might use them?

A: Those are all excellent questions: the kind that everyone should ask as they begin to dig deeper into the Java language and object-oriented programming in general.

Om du bruger:
  private HashMap m;
eller:
  private Map m;
betyder ikke ret meget.

Hvis du får lyst til at skifte fra HashMap til TreeMap så retter du bare i din klasss.

public HashMap dosomething(HashMap m) {

bør absolut være:

public Map dosomething(Map m) {

fordi hvis du får lyst til at rette i implementationen fra HashMap til TreeMap,
så skal alt den kode der bruger klassen ændres. Og i store projekter kan det
være tusinder af klasserr.

Ved at bruge interfaces kan man derfor ændre implementation en uden
at der skal rettes i noget af den kode der bruger det.

Og det er godt.

Puha, der følger en ordentlig smøre på http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html

Argumentet har selvfølgelig ikke den store betydning for et 3 klassers
projekt, men man kan jo ligeså godt lære gode vaner som dårlige vaner.

:-)

Jeg kan kun se brugen af abstrakte klasser, som noget med benytter fordi OO design siger det. F.eks., hvis man forstiller sig, at Mand og Kvinde arver fra menneske giver det ikke mening at instansiere Menneske, men derimod giver det mening at gøre det ved Mand og Kvinde. Hvorfor så ikke lave et interface, der hedder MenneskeIF og lade Mand og Kvinde implementere det..

Det er vel også en pointe i artiklen ca. 1/3 nede:
Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses the ArrayList's clear() method to pop everything off the stack.

Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.

Nej.

En abstrakt basisklasse er yderst fornuftig mekanisme som man tit kan
have meget brug for.

Problemet i det refererde eksempel er at det ikke er en ægte arv.
En stak er *ikke* en specialisering af en ArrayList. Og derfor bør
den ikke extende ArrayList. Det kan være en klasse som indeholder
en ArrayList. Man har altså overtrådt en helt fundamental regel
for arv og har fået et problem. Ikke noget overraskende i det.

[ArrayList er iøvrigt slet ikke abstrakt]

Så generelt er det et spørgsmål om at abstrahere så meget, som muligt?

arne >> Det er jeg glad for du siger, for jeg undrede mig en del over afsnittet med ArrayList.

I øvrigt en fin artikel fra JavaWorld da fandt dougheffernan.

Så hvis man holder et interface op imod en abstrakt klasse (som f.eks. 08/08-2003 15:38:22), er den abstrakte klasse vel kun en fordel, da der ikke kan laves objekter af den.

Hele formålet med OOP (som med alle de foregående programmeings paradigmer)
er at reducere omkostningen til udvikling og vedligehold. Det drejer sig
om at gøre koden nem at overskue. Og det drejher sig om at man skal
kunne ændre et sted i koden uden at skulle ændre 10000 andre steder.

Et interface er en kontrakt. Den her klasse sværger at have en metode
der gør det og det. Det er fy fy nogensinde at fjerne metoder fra
interfaces eller ændre deres signatur. Det er en lang tids kontrakt.

Anden kode kan derfor udvikles udfra en forudsætning om at den kontrakt
holder. Implementationen kan ændres, fejl kan rettes, det hele kan redesignes
for at få bedre performance etc.. Det påvirker ikke kontrakten og derfor
påvirker det ikke andre.

En abstrakt basis-klasse er et fundament i arv. Det er faktisk ret
sjældent at det giver mening at extende en konkret (ikke abstrakt)
klasse. Det er meget sjældent at det giver mening at have en instans
af noget at have en instans af en specialisering af det første.
Det hnder men er sjældent. Men der er jo generaliseringer/specialiseringer.
Og basis-klasser vil typisk være abstrakte. De har nogle generelle
egenskaber. Men kan forekomem rkun som specialiseringer der tilføjer
et eller andet specifikt.

De er helt forskellige.

Et interface er en konktrakt.

En abstrakt basis-klasse er en generalisering af egenskaber.

Man kan ikke instantiere nogen af dem.

Et interface kan siges at være en speciel abstrakt basis-klasse
uden nogen metode implementation (og det er faktisk sådan at
interfaces er defineret i C++).

Ok. Der faldt nogle brikker på plads! Så hans artikel er faktisk noget skidt for en begynder som mig. Jeg symes den forvirre, men er ok som oplæg til en diskussion.

Men iøvrigt er betragtningen om at der extendes for meget rigtig.

Man skal tænke sig lidt om. Og hvis ikke både sup og sub klasse
er designet til det fra start af, så vil encapsulation ofte
være bedre end arv.

ArrayList er f.eks. ikke designet til at blive extended.

Ja, der findes vist ingen forkromet svar på, hvornår det ene er bedre end det andet. En vurderingssag. Men dine informationer har hjulpet mig meget.. Tror, der er mange nye udviklings-aspiranter, der er meget i tvivl om dette.

Jeg ved ikke om det er en dårlig artikel.

Indholdet er både relevant og rigtigt.

Men den giver måske mest mening, hvis man selv har lidt
erfaringer med nogle af de ting der kan gå galt.

Som med så meget andet så skal man tænke selv.

Og vær glad for det. Ellers blev vi jo erstattet af programmer.

*g* Ja.. Det er tankevækkende!