08 – Mere OO Indkapsling Arv og polymorfi (OOP’s 3 hovedprincipper) Advarsel: slides fra foregående præsentation kan forekomme

OO-Principper -indkapsling Et objekt er (set udefra) en atomar enhed der tilbyder en række services (metoder/properties). Det at gøre detaljerne i objekters implementation utilgængelige kaldes information hiding. Det at gruppere data sammen med operationer på disse data under praktisering af information hiding kaldes indkapsling eller dataabstraktion. Indkapsling er et af hovedprincipperne i OOP

Definition af objekt og klasse En repræsentation af et koncept fra virkeligheden, realiseret vha. data knyttet til dette koncept samt en række funktioner gennem hvilke objektet kan ændre eller aflæse egne data. Klasse En type, som definerer de data og funktioner der er nødvendige for at beskrive en gruppe af objekter som alle repræsenterer samme koncept fra virkeligheden. Klassen ”definerer objekternes udseende” og objekter er fysiske forekomster af klassen Klassen er statisk – eksisterer på compiletime. Objekter er dynamiske – eksisterer på runtime.

Attributter (data) Attributterne definerer de data vi ønsker at registrere. Attributterne defineres på klassen, og bliver tildelt en konkret værdi i objekterne. Kontos attributter: kontonummer, saldo, bevilget overtræk, rente mm. Ansat navn, afdelingsnummer, løn, titel mm. Et objekts tilstand kan beskrives som attributternes værdi på et givet tidspunkt

Det er kald til metoderne der får objektet til at ændre tilstand Konto Metoder (funktioner) Objektets funktioner er givet ved de metoder der er tilknyttet objektet. Disse metoder defineres (kodes) i klassen. Det er kald til metoderne der får objektet til at ændre tilstand Konto Haev(), Indsaet(), GetSaldo() osv. Ansat GivLoenforhoejelse(), SetTitel() osv.

Constructor Er en bestemt metode, som skal have samme navn som klassen. Dens opgave er at initialisere objektet under oprettelse. Eksempel på oprettelse af objekt Konto k = new Konto(); Konto() er et kald til Konto-klassens constructor Det er new, der opretter plads til objektet i hukommelsen sørger for at variabelnavnet (referencen) refererer til dette stykke hukommelse – new er i virkeligheden en funktion der returnerer en heap-adresse Constructors kan overloades

Opbygning af klasser Klasser bygges op efter skabelonen: class Klassenavn { dataerklæringer constructors properties metoder }

Acessmodifier: public/private Opbygning af metoder En metode bygges op efter skabelonen accessmodifier returtype Metodenavn (parameterliste) { sætninger } public int SumAfToHeltal (int tal1, int tal2) { int sum; sum = tal1 + tal2; return sum; Lokal variabel return Parametre Acessmodifier: public/private

Nedarvning -generelt Alle metoder bortset fra constructors arves. private medlemmer af basisklassen nedarves, men kan ikke tilgås direkte. Alle protected medlemmer af basisklassen er synlige nedad i arvehierakiet, men private for alle klasser udenfor. Der kan tilføjes attributter og metoder i den nedarvede klasse Ingen multipel arv I Java arver alle klasser fra Object

OO-Principper -nedarvning Nedarvning understøtter kodegenbrug Nedarvning gør det muligt at udvide en eksisterende klasse. Nedarvning er typespecialisering, dvs. vi modellerer et ”er-en” forhold mellem den nedarvede klasse og den der arves fra - fx: en Checkkonto er-en Konto. Hvis vi står og mangler en klasse som er en specialisering af en klasse vi har, kan vi anvende nedarvning. Fx Konto -> CheckKonto

OO-Principper -nedarvning Den der arves fra kaldes basisklasse/superklasse. Den der arver kaldes subklasse Husk at der gælder et er-en forhold mellem sub- og basisklassen En nedarvet klasse er typekompatibel med basisklassen: CheckKonto ck = new CheckKonto(); If (ck instanceof Konto) returnerer true hvis CheckKonto arver fra Konto Er-en forholdet er transitivt.

Nedarvning - Constructors Basisdelen af en nedarvet klasse initialiseres ved kald til this(param-liste). Kald til forfaders constructor er det første der sker i den nedarvede klasses constructor. this(param-liste) placeres først constructoren Hvis man ikke definerer en constructor, genereres en default. Ved nedarvning kalder denne implicit en default constructor (parameterløs) på basisklassen.

Nedarvning - redefinering En basisklasse-metode kan redefineres i den nedarvede klasse Fx Haev-metoden på en Konto/CheckKonto En override-metode tilsidesætter basisklassens metode. Metoden i den nedarvede klasse skal have samme signatur og returtype som den virtuelle den redefinerer. En redefineret metode kan kalde den metode den redefinerer i superklassens vha. this.metodenavn();

Nedarvning - polymorfi Alle referencevariabler i Java kan referere objekter af nedarvede typer – (polymorf = mange former). Ved virtuelle metoder træffes der beslutning på run-time om hvilken metode der skal kaldes (erklæret med @override). Metoden der kaldes er den der er defineret på det objekt referencen i øjeblikket refererer. Dette kaldes dynamisk binding.

Polymorfi/Dynamisk binding Statisk type Dynamisk type Som vi plejer at se det: Ansat programmør = new Ansat("KodeKarl","Programmør",22222); Statisk type = Dynamisk type Statisk metodekald Statisk type Dynamisk type Med polymorft typesystem: Ansat chef = new Chef(”Bosse",”Direktør",52525, 500); Dynamisk type er samme som eller arving til statisk type Compiler checker på statisk type om metode eksisterer, kald til metode vha. dynamisk binding Dynamisk binding forudsætter at metoder er erklæret virtual

Substitutionsprincippet Den dynamiske type skal altid kunne bruges i stedet for den statiske Dvs., at objekter af en nedarvet type skal kunne anvendes i stedet for objekter af den oprindelige De skal kunne substitueres Dette sikres ved at vi ved redefinering af methoder kun afsvækker pre-betingelser og strammer post-betingelser.

Nedarvning - designovervejelser Lad os antage at vi skal bruge en klasse der kan indeholde en liste af ansatte, hvor det er muligt at tilføje sidst i listen, men ikke midt i – Skal vi arve fra Array, ArrayList eller? Nej vi skal ikke arve, men bruge delegation Arv bør ikke bruges blindt for at opnå kodegenbrug - arv er typespecialisering! Arv skal kunne forsvares logisk som en ”A er-en B” Kodegenbrug kan i stedet opnås ved at bygge oven på eksisterende klasser. Kaldes også for komposition, delegering, mm.

Nedarvning - abstract En klasse som indeholder en eller flere metoder som ikke er defineret kaldes abstrakt En abstrakt klasse bruges kun i forbindelse med arv, og kan ikke instantieres, dvs. der kan ikke oprettes objekter af en abstrakt klasse. En abstrakt metode skal redefineres i de(n) nedarvede klasse(r). En abstrakt metode definerer funktionalitet for alle arvinger (men implementerer ikke). En constructor i en abstrakt klasse bruges kun af arvingernes constructors

Designeksempel: Composite-pattern Composite: Grafisk editor, Tekstbehandling, Køkkenlager mmm. Hvordan ser en Show-metode ud på Shape, Circle og Picture Har I en løsning?

NOEA - Nordjyllands Erhvervsakademi FEN 2008-08-28 abstract public class Shape{ protected Position pos; //figurens position protected Color color; //figurens farve //øvrige attributter   public virtual void MoveTo(Position newPos){ // PRE none // POST pos'=newPos } public abstract void Show(); // Abstrakt operation // - kan ikke implementeres for en vilkårlig figur. // POST figuren er tegnet public abstract void Hide(); // POST figuren er skjult // øvrige operationer }//end Shape NOEA - Nordjyllands Erhvervsakademi FEN 2008-08-28

NOEA - Nordjyllands Erhvervsakademi FEN 2008-08-28 public class Circle: Shape{ private int r; //radius //øvrige attributter - pos og color arves public override void Show(){ //PRE none //POST cirklen er tegnet //Denne operation kan nu implementeres for en cirkel //ved hjælp af en passende grafikrutine. } public @Override void Hide(){ //POST cirklen er skjult // øvrige operationer - MoveTo() arves} }//end Circle; NOEA - Nordjyllands Erhvervsakademi FEN 2008-08-28

Dynamisk type definerer Show() public class Picture: Shape{ private ArrayList shapes; // operationer til at tilføje og slette figurer mv. public void override Show(){ //PRE none //POST den sammensatte figur er tegnet for(Shape s : shapes) s.Show(); } public void override Hide(){ //POST den sammensatte figur er skjult s.Hide(); public void MoveTo(Position newPos){ //POST pos'=newPos s.MoveTo(newPos); }//end Picture Statisk type Dynamisk type definerer Show()

Composite Pattern The concept of patterns originates from architecture (Christopher Alexander, 1977): “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” (Christopher Alexander e. a.: “A Pattern Language”. Oxford University Press, New York, 1977.)

(OO) Design Patterns A well known and widely accepted concept in software engineering Developed in the early 1990s and published by Gamma e.a. (“Gang of Four”, GoF) in 1995: “(…) design patterns (…) are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” (Erich Gamma e.a.:”Design Patterns. Elements of Reusable Object-Oriented Software”. Addison-Wesley. 1995.)

The benefits of patterns A pattern captures a proven good design: A pattern is based on experience A pattern is discovered – not invented It introduces a new (and higher) level of abstraction, which makes it easier: to talk and reason about design on a higher level to document and communicate design One doesn’t have to reinvent solutions over and over again Patterns facilitate reuse not only of code fragments, but of ideas.

Patterns as a learning tool It is often said that good skills in software construction require experience and talent …and neither can be taught or learned at school Patterns capture experience (and talent) in a way that is communicable and comprehensible …and hence experience can be taught (and learned) So one should put a lot of effort in studying patterns

Eksempel: Organisation Samme pattern som Shape Organsatorisk enhed Team Afdeling