FEN NOEA - Nordjyllands Erhvervsakademi1 Objektorienteret programmering Indkapsling Arv og polymorfi (OOP’s 3 hovedprincipper)

FEN NOEA - Nordjyllands Erhvervsakademi2 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

FEN NOEA - Nordjyllands Erhvervsakademi3 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.

FEN NOEA - Nordjyllands Erhvervsakademi4 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

FEN NOEA - Nordjyllands Erhvervsakademi5 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.

FEN NOEA - Nordjyllands Erhvervsakademi6 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(?)

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;} }

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;

FEN NOEA - Nordjyllands Erhvervsakademi9 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

FEN NOEA - Nordjyllands Erhvervsakademi10 Opbygning af klasser Klasser bygges op efter skabelonen: class Klassenavn { dataerklæringer constructors properties metoder }

FEN NOEA - Nordjyllands Erhvervsakademi11 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; } Acessmodifier: public/private Lokal variabel return Parametre

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

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

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

FEN NOEA - Nordjyllands Erhvervsakademi15 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

FEN NOEA - Nordjyllands Erhvervsakademi16 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

FEN NOEA - Nordjyllands Erhvervsakademi17 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.

FEN NOEA - Nordjyllands Erhvervsakademi18 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.

FEN NOEA - Nordjyllands Erhvervsakademi19 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();

FEN NOEA - Nordjyllands Erhvervsakademi20 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.

FEN NOEA - Nordjyllands Erhvervsakademi21 Polymorfi/Dynamisk binding 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 Dynamisk type Statisk type

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

FEN NOEA - Nordjyllands Erhvervsakademi23 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.

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

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

FEN NOEA - Nordjyllands Erhvervsakademi26 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.

FEN NOEA - Nordjyllands Erhvervsakademi27 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

FEN NOEA - Nordjyllands Erhvervsakademi28 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?

FEN NOEA - Nordjyllands Erhvervsakademi29 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

FEN NOEA - Nordjyllands Erhvervsakademi30 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;

FEN NOEA - Nordjyllands Erhvervsakademi31 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 Dynamisk type definerer Show() Statisk type

FEN NOEA - Nordjyllands Erhvervsakademi32 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.)

FEN NOEA - Nordjyllands Erhvervsakademi33 (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 )

FEN NOEA - Nordjyllands Erhvervsakademi34 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.

FEN NOEA - Nordjyllands Erhvervsakademi35 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

FEN NOEA - Nordjyllands Erhvervsakademi36 Eksempel: Organisation Organsatorisk enhed TeamAfdeling