Objektorienteret programmering

FEN 2008-08-28 NOEA - Nordjyllands Erhvervsakademi 1

Objektorienteret programmering

Indkapsling

Arv og polymorfi

(OOP’s 3 hovedprincipper)


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

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


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


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.


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;


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

}


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

Projekt

navnafdeling

GetTotalTimer()TilknyMedarbejder()GetMedarbejdere()

Ansat

navnstillingløn

ArbejderPaa

timer10..* 10..*1 0..*1 0..*

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


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


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 is Konto) returnerer true hvis CheckKonto arver fra Konto

• Er-en forholdet er transitivt.


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.


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();


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.


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


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

Projekt

navnafdeling

ArbejderPaa

timer10..* 10..*

Ansat

navnstillingløn 1 0..*1 0..*

Chef

antalOptioner

Sælger

antalSolgteEksemplarer

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


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

1

Circle Rectangle Picture

Shape

0..*0..*

Position

1

Composite: Grafisk editor, Tekstbehandling, Køkkenlager mmm.

Hvordan ser en Show-metode ud på Shape, Circle og Picture

Har I en løsning?


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


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;


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


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

Organsatorisk enhed

Team Afdeling

Documents

Objektorienteret programmering