08 – Mere OO

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

2. 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

3. Definition af objekt og klasse • Objekt • 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.

4. 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

5. 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.

6. 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

7. Opbygning af klasser Klasser bygges op efter skabelonen: classKlassenavn { dataerklæringer constructors properties metoder }

8. 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

9. 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 C# arver alle klasser fra Object

10. 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

11. 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 is Konto) returnerer true hvis CheckKonto arver fra Konto • Er-en forholdet er transitivt.

12. Nedarvning - Constructors • Basisdelen af en nedarvet klasse initialiseres ved kald til base(param-liste). • Kald til forfaders constructor er det første der sker i den nedarvede klasses constructor. • :base(param-liste) placeres umiddelbart efter constructorens metodehoved – notation taget fra C++ • Hvis man ikke definerer en constructor, genereres en default. Ved nedarvning kalder denne implicit en default constructor (parameterløs) på basisklassen.

13. Nedarvning - redefinering • En basisklasse-metode kan redefineres i den nedarvede klasse • Fx Haev-metoden på en Konto/CheckKonto • En basisklasse-metode der skal redefineres i den nedarvede klasse, skal erklæres virtual i basisklassen, og eksplicit overrides i den nedarvede klasse. • 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. base.metodenavn();

14. Nedarvning - polymorfi • Alle referencevariabler i C# 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. • Metoden der kaldes er den der er defineret på det objekt referencen i øjeblikket refererer. • Dette kaldes dynamisk binding.

15. Polymorfi/Dynamisk binding Statisk type Som vi plejer at se det: Ansat programmør = new Ansat("KodeKarl","Programmør",22222); Statisk type = Dynamisk type Statisk metodekald Dynamisk type 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

16. 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.

17. 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.

18. 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

19. 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?

20. 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. // PRE none // POST figuren er tegnet public abstract void Hide(); // Abstrakt operation // - kan ikke implementeres for en vilkårlig figur. // PRE none // POST figuren er skjult // øvrige operationer }//end Shape NOEA - Nordjyllands Erhvervsakademi

21. 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(){ //PRE none //POST cirklen er skjult //Denne operation kan nu implementeres for en cirkel //ved hjælp af en passende grafikrutine. } // øvrige operationer - MoveTo() arves} }//end Circle; NOEA - Nordjyllands Erhvervsakademi

22. 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(){ //PRE none //POST den sammensatte figur er skjult for(Shape s : shapes) s.Hide(); } public void MoveTo(Position newPos){ //PRE none //POST pos'=newPos for(Shape s : shapes) s.MoveTo(newPos); } }//end Picture Statisk type Dynamisk type definerer Show()

23. 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.)

24. (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.)

25. 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.

26. 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

27. Organsatorisk enhed Team Afdeling Eksempel: OrganisationSamme pattern som Shape