Klasser og objekter?

[Ayjay]

Er det noen som kan forklare meg hva klasser og objekter er, og hva de brukes til i objektorientert programmering?

 

Har prøvd å lese, men finner ikke helt ut hva jeg skal bruke dem til.

 

Mvh andreas

[Unlimited LTD]

Kort sagt: Klasser er en type ting. F.eks. katt.

En katt har flere variabler, som f.eks. sulten, farge på pelsen og navn.

En katt har også metoder, det er f.eks. male, spise eller klore på sofaen.

 

Men det finnes jo ikke bare en katt. Du har jo mange katter, og alle kattene har jo disse variablene og metodene. Så da har du kanskje en katt som heter eugen.

Da får du:

 

Katt eugen = new Katt();

 

Dette oppretter en instans av typen katt (altså, den oppretter en ny katt), med navnet eugen. eugen er nå et objekt, av klassen Katt.

Videre kan du jo kalle på metoden spise, som setter variablen sulten til 'false'.

 

eugen.spise();

 

Da kalles metoden som er felles for alle katter, definert i klassen Katt, og setter variablen sulten til eugen til 'false'.

 

Så kan du jo lage en ny katt, garfield.

 

Katt garfield = new Katt();

 

garfield deler metoder med eugen, men bare selve koden. Så dersom metoden male var definert slik:

public void male(){
  System.out.println("Maler");
}

Så ville både kallet eugen.male() og garfield.male() gjort det samme.

 

Men hvis vi ser på metoden spise:

public void spise(){
	sulten = false;
}

Denne metoden er definert i klassen Katt. Men det er ikke det samme om du kaller eugen.spise() eller garfield.spise().

Hvis du kaller eugen.spise() så blir eugen sin sulten satt til 'false'. Men garfield sin sulten er fremdeles 'true'. Det er fordi sulten er en variabel som er forskjellig fra hver katt.

 

Et mer riktig eksempel er f.eks. en klasse som heter Kort.

Kort klassen representerer et kort fra en kortstokk, og har derfor to variabler, farge(ruter, spar, ess og kløver) og tall (1-13)

public class Kort{ // Definerer klassen
  public String farge; // farge og tall er variabler som er forskjellige fra hvert kort.
  public int tall;

  public static void main(String args[]){ // Startpunktet i programmet
  Kort sparEss = new Kort();
  sparEss.farge = "Spar"; // farge er en string
  sparEss.tall = 1;
  Kort sparTi = new Kort();
  sparEss.farge = "Spar"; // farge er en string
  sparEss.tall = 10;
  //Nå har både sparEss og sparTi Spar som farge, sparEss har 1 som tall, og sparTi har 10 som tall.
  }
}

 

Og det fine med klasser er at man kan arve. F.eks. kan klassen Katt arve fra klassen firbent, som igjen arver fra klassen pattedyr, som igjen arver fra klassen dyr.

Og alle metoder og variabler som er definert i f.eks. pattedyr, som kanskje farge, er tilgjengelig for alle klasser som arver fra den.

 

Så i det tilfellet over vil man kanskje definere farge i klassen dyr, da alle dyr har en eller annen farge. Det vil si at alle dyr, både hunder og katter, eller hvaler, har variablen farge.

 

Håper dette hjalp litt med forståelsen. Det er selvsagt mye mer å lære om dette, men dette bør gi en grei forklaring.

[quantum]

Se også

 

http://en.wikipedia.org/wiki/Object_orient...ts_and_features

 

Som allerede nevnt gjør objektorientering det enklere å representere fenomener i virkeligheten, f.eks. Katt, eller en rad i en databasetabell.

 

Den andre store fordelen er at objektorientering gir gode muligheter til å strukturere programvare og interaksjon mellom ulike programvarekomponenter på en fornuftig måte gjennom innkapsling av data og metoder i enheter. Man definerer da grensesnitt (interface) som beskriver metodene i disse enhetene.

 

La oss si du har et klassehierarki som nevnt over med ymse former for dyr, inkludert f.eks. Pattrdyr, Hund, Katt og Hest i opplagt hierarkisk relasjon.

 

Og så kan vi ha et tilsvarende hierarki med f.eks. maskineri, f.eks. Maskin, ManuellMaskin, ElektriskMaskin, DrivstoffbasertMaskin, Brødrister og Bil, i et hierarki.

 

Grunnen til at vi har valgt to separate hierarkier er at vi synes disse er for ulike til at det gir mening å hekte dem sammen, og vi ser for oss at vi ønsker å videreutvikle dem uten å være hindret av eventuelle «unaturlige» hierarkirelasjoner.

 

Men så ønsker vi å lage f.eks. et program som håndterer transport av ulike ting. Vi vil f.eks. ønske oss metoder som kan fortelle oss hvor mange enheter vi må fordele lasten over, og hvor lang tid transporten vil ta osv. Vi kan da gjøre som følger:

 

Vi definerer et grensesnitt Transportør (i java heter dette interface). F.eks.

 

public interface Transportør {
 public int getMaxLast();
 public int getMaxFart();
}

 

Noen kaller interfaces for kontrakter, fordi man anser at det er noe klasser kan «påta» seg, uten at man trenger forholde seg til hvordan det blir utført (implementert). Dette gir enormt stor fleksibilitet i forhold til hvordan man kan sette sammen og gjenbruke programvarekomponenter. Man aner ikke hvaslags objekttype man bruker, man vet bare at den kan utføre visse operasjoner.

 

I eksempelet kan vi tenke oss at vi lar Bil, Båt og Hest implementere Transportør, men ikke Maskin, Katt, Pattedyr. Poenget er at vi da får muligheten til å bruke disse klassene som egentlig ikke har noe med hverandre å gjøre på samme måte.

 

Eks:

 

public class Hund extends Pattedyr implements Transportør {
...

  public int getMaxFart() {
  return getAntallBein() * getLengdeBein();
  }
  public int getMaxLast() {
  return getAntallBein() * getTykkelseBein();
  }
...
}

public class Bil extends Motorvogn implements Transportør {
...
  public int getMaxFart() {
  return getHk() * getHjul().getDiameter();
  }
  public int getMaxLast() {
  return getHjul().getAntall() * getHjul().getDiameter() * getHjul().getBredde();
  }
...

public class TranportManager {
{
  public float getTranportEnheter(Transportør transportør, int vekt) {
  return vekt / transportør.getMaxLast();
  }
  ...
}

 

Nå skal vi ikke henge oss opp i tvilsom implementasjon og avrundingsproblematikk her, men bare konstantere at vi har klart å la to urelaterte objekttyper påta seg samme type arbeidsoppgave i en gitt sammenheng. Dog, vi har gjort en liten blemme i definisjonen av vårt interface. Det kunne med fordel vært mer abstrakt. Et lyst hode har nemlig funnet ut at vi kan bruke ulike organisasjoner, f.eks. budfirma, til transport. Et budfirma har ingen maxfart og maxlast (de har jo i praksis det, men la oss anta at vi ikke møter taket her, vi kommer ikke til å fylle opp et godstog eller en oljetanker), og kan heller ikke oppfylle Transportør-interfacet slik det er definert.

 

Vi skriver det derfor om slik at det isteden har metodene getKostnad() og getTid(). Vi må da skrive om klassene som implementerer Transportør også. Det er kjedelig, men det lar seg gjøre og er egentlig ganske trivielt. Det hadde vært mye vanskeligere å prøve å tvinge et klassehierarki med ulike typer Organisasjoner inn i det allerede tvilsomme felleshierarkiet for Maskiner og Vesener, for at de skulle kunne arve disse metodene seg imellom.

 

Så moralen er at man kan gjerne blande fugl og fisk i et klassehierarki, men ikke alt mulig annet også. For å knytte sammen «ting» som egentlig ikke har noe med hverandre å gjøre i en gitt sammenheng bruker man isteden grensesnitt/interfaces.

[duckers]

Kan vi ikke si det enklere?

 

En klasse er en samling av programkode. Poenget med en klasse er å skjule implementeringen av programmet for utvikleren. Har du en katt trenger du ikke vite hvordan denne katten fungerer, annet en internt i klassen.

 

Et objekt er en klasse som "kjører". Altså når du skriver

Katt pus = new Katt("pus");

så oppretter du et objekt av klassen Katt.

[Johan]

Jeg liker å se på det "den andre veien rundt".

 

I OO deler vi verden inn i objekter, konkrete eller abstrakte. Karsten, Per og Siri er objekter, men de har også mye til felles, de er alle Personer. Vi kan klassifisere disse tre som objekter av klassen Person. Videre har jo disse tre forskjellig navn, derfor lager vi et felt i Person-klassen hvor dette kan komme til utrykk.

 

I praksis ser vi på problemområdet og opretter klasser der vi ser at mange objekter har mye tilfelles med hverandre. Samtidig må vi huske å kun modellere/programmere data og oppførsel som er interessant for oss gitt problemstillingen. Karsten, Per og Siri har sikkert veldig forskjellige hobbyer, men lager vi en telefonkatalog er jo ikke dette av noen betydning.

[quantum]

Kan vi ikke si det enklere?

jo selvfølgelig, men du har jo hoppet over mesteparten ...