Objektorienteret programmering

1. Objektorienteret programmering Indkapsling Arv og polymorfi (OOP’s 3 hovedprincipper) NOEA - Nordjyllands Erhvervsakademi

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 NOEA - Nordjyllands Erhvervsakademi

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. NOEA - Nordjyllands Erhvervsakademi

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 NOEA - Nordjyllands Erhvervsakademi

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. NOEA - Nordjyllands Erhvervsakademi

6. Properties • Bruges til at sætte og aflæse værdien af objektets attributter • Svarer til set- og get-metoder • En set-metode ændrer værdien af en attribut • En get-metode aflæser værdien af en attribut • Giver en syntaks som om man tilgår en attribut • En Anders Hejsberg(?) NOEA - Nordjyllands Erhvervsakademi

7. Properties public class Kunde { private int kundenummer; private string navn; public string Navn{ get{ return navn;} set{ navn = value;} } public int Kundenummer { get{return kundenummer;} } } }

8. Brug af properties Kunde k = new Kunde(”Jens Jørgensen”); k.Navn = ”Jens Petersen”; string navn = k.Navn; k.navn = ”Jens Petersen”; //fejl private attribut k.Kundenummer = 21; //fejl read-only int x = k.Kundenummer;

9. 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 NOEA - Nordjyllands Erhvervsakademi

10. Opbygning af klasser Klasser bygges op efter skabelonen: classKlassenavn { dataerklæringer constructors properties metoder } NOEA - Nordjyllands Erhvervsakademi

11. 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 NOEA - Nordjyllands Erhvervsakademi

12. Access Modifiers • Public • Kan tilgås af alle metoder fra alle objekter • Private • Kan tilgås af den definerende klasses medlemmer og ikke andre • Protected • Kan tilgås af klassen selv og af arvinger – privat for alle andre • Internal • Kan tilgås af den definerende klasse og alle klasser i samme assembly • Protected internal • Kan tilgås af den definerende klasse, klasser i samme assembly og fra arvinger

13. Eksempel på realisering af domænemodel • Del af design-klassediagram i et system til registrering af ansatte og projekter

14. Realisering af objektforbindelse • Designovervejelser • Hvilken vej skal objekterne kunne tilgås • Forbindelse til 1 objekt • Simpel objektreference • Forbindelse til * objekter • Reference til collection på 1-siden

15. 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 NOEA - Nordjyllands Erhvervsakademi

16. 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 NOEA - Nordjyllands Erhvervsakademi

17. 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. NOEA - Nordjyllands Erhvervsakademi

18. 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. NOEA - Nordjyllands Erhvervsakademi

19. 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(); NOEA - Nordjyllands Erhvervsakademi

20. 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. NOEA - Nordjyllands Erhvervsakademi

21. 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 NOEA - Nordjyllands Erhvervsakademi

22. Nedarvning- override af ikke-virtual metoder • Hvad nu hvis vi glemmer at gøre vores metoder virtual, og en anden senere vil arve en af vores klasser og override en metode? • Svaret er new foran override-metoden

23. 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. NOEA - Nordjyllands Erhvervsakademi

24. Arv- Vi vil udvide domænemodellen fra før

25. Polymorfi- redefinering af metoder • Først implementerer vi metoden GivBonus(int belob) som virtual i klassen Ansat • Herefter redefiner vi den i klasserne Chef og Saelger • Endelig oprettes et array af Ansatte i main, hvor alle medarbejdere får 500,- i bonus

26. 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. NOEA - Nordjyllands Erhvervsakademi

27. 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 NOEA - Nordjyllands Erhvervsakademi

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

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

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

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

32. 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.) NOEA - Nordjyllands Erhvervsakademi

33. (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.) NOEA - Nordjyllands Erhvervsakademi

34. 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. NOEA - Nordjyllands Erhvervsakademi

35. 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 NOEA - Nordjyllands Erhvervsakademi

36. Organsatorisk enhed Team Afdeling Eksempel: Organisation NOEA - Nordjyllands Erhvervsakademi