Grundbegreber fra objektorienteret design

Præsentationer af emnet: "Grundbegreber fra objektorienteret design"— Præsentationens transcript:

1 Grundbegreber fra objektorienteret design
Designmønstre Grundbegreber fra objektorienteret design

2 Emner Modellering Introduktion til interfaces Design med interfaces
begrebsapparat og UML Introduktion til interfaces eksempel, interfacebegrebet, og kontraktbaseret design Design med interfaces hvordan og hvornår? Design med komposition frem for arv ”inheritance considered harmful” Generisk kode programmering mod (parametriserede) interfaces Cryptomathic, F05 Designmønstre

3 Modellering Begrebsapparat og UML

4 Conceptual Modelling Problem domain Model modelling Conceptual model
Specification model abstraction abstraction Problem/vision concerning phenomenons Program, language, OS, machine Problem domain Model Cryptomathic, F05 Designmønstre

5 UML Unified Modeling Language Result of collaboration among
Grady Booch James Rumbaugh Ivar Jacobson Rational  OMG (Object Management Group) De facto standard for software modelling UML Resource Center Introduction to the Unified Modeling Language (Terry Quatrani) Cryptomathic, F05 Designmønstre

6 Concept Formation Identification of phenomena Classification Person
Socrates Batmobile Hannibal’s march across the Alps Neil Young Sirius 2000 Herbie Hillary Clinton Classification Person Socrates Neil Hillary Car Batmobile Herbie Journey Sirius 2000 Hannibal’s march across the Alps Cryptomathic, F05 Designmønstre

7 Classification in UML Classes represent concepts,
objects represent phenomenons. Example Concept: Person Phenomenons: Bruce, Paul, Michael Person isTeenager() isOld() age() String name int age Class : Person ”Bruce” 55 ”Paul” 62 ”Michael” 44 Objects Cryptomathic, F05 Designmønstre

8 Classification in Java
class Person { private String name; private int age; public Person(String name, int age) { this.name = name; this.age = age; } public void birthday() { age++; public isTeenager() { return (age >= 13 && age <= 19) List l = new ArrayList(); l.add( new Person(”Bruce”, 55) ); l.add( new Person(”Paul”, 62) ); l.add( new Person(”Michael”, 44) ); Cryptomathic, F05 Designmønstre

9 Relations between concepts
Aggregation has-a Association X-a Generalization/specialization is-a Organization of knowledge... Cryptomathic, F05 Designmønstre

10 Aggregation (has-a) Relation between concepts describing a whole and (some of) the parts of which constitutes the whole (part-whole structure). UML: Composition Car Motor Wheel Body Seat Door Roof Fender Journey Duration Departure Means of transportation Destination Cryptomathic, F05 Designmønstre

11 Aggregation in UML (1) ClockDisplay NumberDisplay hours;
NumberDisplay minutes; String displayString; timeTick() setTime(int h, int m) getTime(): String Cryptomathic, F05 Designmønstre

12 Aggregering i UML (2) NumberDisplay ClockDisplay int limit; int value;
String displayString; 2 timeTick() setTime(int h, int m) getTime(): String getValue() getDisplayValue() setValue() increment() Cryptomathic, F05 Designmønstre

13 Aggregation in Java class NumberDisplay { private int limit, value;
public NumberDisplay() { ... } public int getValue() { ... } public String getDisplayValue() { ... } public void setValue(int replacementValue) { ... } public void increment() { ... } } class ClockDisplay { private NumberDisplay hours; private NumberDisplay minutes; private String displayString; public ClockDisplay() { hours = new NumberDisplay(24); minutes = new NumberDisplay(60); } public void timeTick() { ... } public void setTime(int hour, int minutes) { ... } public String getTime() { ... } Cryptomathic, F05 Designmønstre

14 Association (X-a) Relation that describes a dynamic relation between concepts that can exist independently of each other. MailServer keeps MailItem Person owns Car Person rents Car Person loves Person Person is-friend-with Person Student is-enrolled-at Course Patient have-had Disease Cryptomathic, F05 Designmønstre

15 Association in UML * * * * * MailServer MailItem Person Car Student
keeps * MailServer MailItem owns * Person Car 0..1 owned can-drive * takes Student Course * * Multiplicity (cardinality): 0..1, 1, n, a..b, 0..* (*) Role Orientation (1-way, 2-way) Cryptomathic, F05 Designmønstre

16 Association in UML (X-a)
X = keeps MailItem MailServer from: String to: String message: String 0..* howManyMessages(String who): int getNextMailItem(String who): MailItem post(MailItem item) getFrom(): String getTo(): String getMessage(): String print() Cryptomathic, F05 Designmønstre

17 Association in Java class MailServer { Set messages;
public MailServer() { messages = new HashSet(); } public int howManyMessages (String who) { ... } public MailItem getNextMailItem (String who) public void post(MailItem item) class MailItem { private String to; private String from; private String message; public MailItem( ... ) { ... } public String getFrom() { ... } public String getTo () public String getMessage() public void print() Cryptomathic, F05 Designmønstre

18 Generalization/specialization (is-a)
Combine concepts to a more general concept. Vehicle Car Truck Bus Passenger car Taxi Ambulance Van Sedan Cryptomathic, F05 Designmønstre

19 What makes a concept special?
Means of transportation Plane Passenger plane Airliner Sports plane Military plane Ship Vehicle Car Bus Truck Lorry Pick-up Passenger car Van Taxi Bicycle Figure Ellipse Circle Triangle Isosceles triangle Equilateral Right-angled Four-sided polygon Trapezoid Parallelogram Rectangle Square Kite Adding properties! Cryptomathic, F05 Designmønstre

20 Specialization: extra properties
A concept’s intension: Collection of properties that characterize the concept A concept’s extension: The collection of phenomena covered by the concept A B B is-a A Intension(B) Intension(A) Extension(B) Extension(A)   Cryptomathic, F05 Designmønstre

21 Specialization in UML LendableItem General concept Special concepts
lend(l: borrower) return() isAvalable() Book Video author() publisher() ISBN() producer() format() playingTime() Cryptomathic, F05 Designmønstre

22 Specialization in Java
class LendableItem { void lend(Borrower b) { // code for lend } void return() { // code for return boolean isAvalable() { // code for isAvalable ... class Book extends LendableItem { String author() { ... } String puclisher() { ... } String ISBN() { ... } ... } class Video extends LendableItem String producer() { ... } String format() { ... } int playingTime() { ... } Cryptomathic, F05 Designmønstre

23 Concept formation and oo-languages
Classification Aggregation has-a Association X-a Specialization is-a class Reference (attribute) aggregate has responsibility for the creation dynamic relation extends subtype Cryptomathic, F05 Designmønstre

24 Systematics in OOP Modelling Implementation
from problem description to conceptual model refinement of conceptual model to specification model (method signatures and specifications) Implementation structurally: from specification model to Java code (automatically) body: attributes and methods (creativity and systematics) Problem domain Cryptomathic, F05 Designmønstre

25 Conceptual Modelling Designmønstre Problem domain Model modelling
Specification model abstraction abstraction Problem/vision concerning phenomenons Program, language, OS, machine Problem domain Model Cryptomathic, F05 Designmønstre

26 Interfacebegrebet Interfaces, hvorfor Interfaces, hvad
Separering af specifikation (interface) og implementation (klasse) Modellering (abstrakt/konkret, generelt/specielt) Afkobling af programkomponenter Interfaces, hvad Mange-til-mange relation mellem specifikation og implementation Typehierarki Interfaces, hvordan Sprogkonstruktion i Java og C# Essentielt begreb i CORBA Java-specifik karakteristik Yet another level of indirection... Cryptomathic, F05 Designmønstre

27 Separering af spec. og impl.
Specifikation (hvad) Beregn xy Sorter listen Rektangel Prioritetskø Implementation (hvordan) lineær potensopløftning logaritmisk potensopløftning Quicksort Mergesort Bobblesort et hjørne og to sidelængder to hjørner array (sorteret) kædet liste (sorteret) søgetræ (balanceret) bunke (heap) Cryptomathic, F05 Designmønstre

28 Interfaces (specifikation) Klasser (implementation)
Modellering Interfaces (specifikation) Containerklasser I Java findes en række collectioninterfaces og –klasser Såvel interfaces som -klasser er organiseret i klassifikations-hierarkier (specialisering) Interfaces er abstrakte, klasser er konkrete Et interface definerer en abstrakt datatype (ADT) En klasser definerer én implementation (datastruktur) HashSet impl Set ArrayList impl List HashMap impl Map TreeSet impl SortedSet LinkedList impl List TreeMap impl SortedMap Klasser (implementation) Cryptomathic, F05 Designmønstre

29 Interface, abstrakt og konkret klasse
Procent implementation 0 % 100 % Interface Abstrakt klasse Konkret klasse Java og C# supporterer interfacebegrebet. I C++ må dette simuleres vha. abstrakte klasser og ”pure virtual functions”. Cryptomathic, F05 Designmønstre

30 Afkobling af programkomponenter
Calculator Stack Simple Scientific ArrayStack LinkedStack Financial CollectionStack Komponenterne kan udskiftes uafhængigt af hinanden dvs. 3  3  9 mulige konfigureringer Cryptomathic, F05 Designmønstre

31 Mange-til-mange relation
Fra spec. til impl. Det er oplagt at en specifikation kan implementeres på mange måder Fra Impl. til spec. Der er måske mindre oplagt at en implementation kan opfylde flere forskellige specifikationer En specifikation udtrykker mindstekrav til en implementation ved at beskrive en rolle som en implementation skal udfylde En implementation kan leve op til flere forskellige mindstekrav / udfylde flere forskellige roller Specifikation ADT interface * * CDT (abstrakt) klasse Implementation Cryptomathic, F05 Designmønstre

32 Eksempel, mange-til-en
interface Rectangle { float circumference(); } interface Comparable { int compareTo(Object o); } class R implements Rectangle, Comparable { private Point p; private int b, h; public circumference() { return 2*(b+h); } public int compareTo(Object o) { ... } ... } UML Java << interface >> Rectangle << interface >> Comparable circumference compareTo R p: Point b: int h: int circumference compareTo Cryptomathic, F05 Designmønstre

33 Typehierarki extends implements Subtype Subtyper i Java () Relationer
udtrykker en generaliserings- / specialiseringsrelation implements udtrykker en abstraktions- / konkretiseringsrelation Subtype Såvel specialisering som konkretisering danner subtype For klassebaserede typer gælder:  Alle typer, T, er subtype af Object: T  Object  Alle typer, T, er subtype af sig selv: T  T  T1  T2  T2  T3  T1  T3  T2  T1, hviss T1 og T2 er defineret på en af følgende tre måder: class T2 extends T1 { ... } class T2 implements T1 { ... } interface T2 extends T1 { ... } Subtyper i Java () Relationer Cryptomathic, F05 Designmønstre

34 Kontraktbaseret design
Kontraktperspektivet to parter gensidige fordele gensidige forpligtigelser Service Forpligtigelser Fordele Skal opfylde start-betingelse Kan antage slut-betingelse Klient Skal opfylde slut-betingelse Kan antage start-betingelse Udbyder Cryptomathic, F05 Designmønstre

35 Design med interfaces Hvordan og hvornår?

36 Hvad er målet med softwaredesign?
Fleksibilitet, fleksibilitet og fleksibilitet Skal kunne ændres uden de store omkostninger Nye ting skal kunne tilføjes Skal kunne tunes (performance) Hvordan når vi målet? Lav kobling Høj samhørighed DeMarco & Page-Jones (1988) Cryptomathic, F05 Designmønstre

37 Kobling Kobling Afhængighed mellem moduler Lav kobling = minimal viden (om implementation) hos den der benytter et modul Benyt interfaces... ...til at modellere de forskellige roller en klasse kan spille Rollebaseret systemudvikling Hvordan finder man roller? Hvordan benytter man roller? Cryptomathic, F05 Designmønstre

38 Rollebaseret design - motivation
Cryptomathic, F05 Designmønstre

39 Rollebaseret design - struktur
Cryptomathic, F05 Designmønstre

40 Benyttelse af roller Vurdér hver association for mulig generalisering:
”Er associationen hardwired til kun at benytte objekter af den anden klasse, eller er det en associering med ethvert objekt der implementerer et givet interface”? Vurdér hvert operationskald for mulig generalisering: ”Er dette metodekald kun til objekter af den givne klasse eller er det til ethvert objekt der implementerer et givet interface”? Cryptomathic, F05 Designmønstre

41 Fordele ved interfaces
Associering til et interface gør koblingen mindre elliminerer potentiel multipel arv Interface udtrykker ”is a kind of” på en meget begrænset form – ”is a kind that supports this interface” Jo større et system er, og jo længere et system skal leve, des vigtigere er interfaces Interfaces definerer ”plug-in”-steder i designet Cryptomathic, F05 Designmønstre

42 Design med komposition frem for arv
”Inheritance considered harmful”

43 Faktorisering af funktioner
class Computation { void method1(...) { // ... computeStep1(); computeStep2(); computeStep3(); //... } void method2(...) { } } class FactorizedComputation { void computeAll(...) { computeStep1(); computeStep2(); computeStep3(); } void method1(...) { // ... computeAll(); //... void method2(...) { } } Kun brugbar når koden ligger inden for samme klasse! Cryptomathic, F05 Designmønstre

44 Faktorisering ved arv class ComputationA { void method1(...) { // ...
computeStep1(); computeStep2(); computeStep3(); //... } class ComputationB {} void method2(...) { class Common { void computeAll(...) { computeStep1(); computeStep2(); computeStep3(); } } class ComputationA extends Common { void method1(...) { // ... computeAll(); //... class ComputationB extends Common { void method2(...) { Cryptomathic, F05 Designmønstre

45 Faktorisering ved delegering
class ComputationA { void method1(...) { // ... computeStep1(); computeStep2(); computeStep3(); //... } class ComputationB {} void method2(...) { class Helper { void computeAll(...) { computeStep1(); computeStep2(); computeStep3(); } } class ComputationA { Helper helper; void method1(...) { // ... helper.computeAll(); //... class ComputationB {} void method2(...) { Cryptomathic, F05 Designmønstre

46 Faktorisering, arv vs. delegering
Cryptomathic, F05 Designmønstre

47 Arv eller delegering? Faktorisering ved arv er ofte simplest, men man kan opnå det samme med faktorisering ved delegering. Singulær arv kan gøre det nødvendigt at benytte faktorisering ved delegering fremfor faktorisering ved arv eksempel: hvis enten ComputationA eller ComputationB skal være subklasse af en klasse (der ikke er Object), er faktorisering ved arv ikke mulig Faktorisering ved delegering kan altid lade sig gøre. Cryptomathic, F05 Designmønstre