Designmønstre. Grundbegreber fra objektorienteret design

Transkript

1 Designmønstre Grundbegreber fra objektorienteret design

2 Emner Modellering 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 Grundbegreber fra objektorienteret design.2

3 Modellering Begrebsapparat og UML

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

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 Grundbegreber fra objektorienteret design.5

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

7 Classification in UML Classes represent concepts, objects represent phenomenons. Example Concept: Person Phenomenons: Bruce, Paul, Michael Class Person String name int age isteenager() isold() age() Objects : Person Bruce 55 : Person Paul 62 : Person Michael 44 Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.7

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() List l = new { ArrayList(); age++; l.add( new Person( Bruce, 55) ); l.add( new Person( Paul, 62) ); public isteenager() l.add( { new Person( Michael, 44) ); return (age >= 13 && age <= 19) Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.8

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

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 Grundbegreber fra objektorienteret design.10

11 Aggregation in UML (1) ClockDisplay NumberDisplay hours; NumberDisplay minutes; String displaystring; timetick() settime(int h, int m) gettime(): String Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.11

12 Aggregering i UML (2) ClockDisplay String displaystring; timetick() settime(int h, int m) gettime(): String 2 NumberDisplay int limit; int value; getvalue() getdisplayvalue() setvalue() increment() Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.12

13 Aggregation in Java class NumberDisplay { private int limit, value; public NumberDisplay() {... public int getvalue() {... public String getdisplayvalue() {... public void setvalue(int replacementvalue) {... class ClockDisplay { public void increment() {... 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 Grundbegreber fra objektorienteret design.13

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 Grundbegreber fra objektorienteret design.14

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

16 Association in UML (X-a) X = keeps MailServer howmanymessages(string who): int getnextmailitem(string who): MailItem post(mailitem item) 0..* MailItem from: String to: String message: String getfrom(): String getto(): String getmessage(): String print() Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.16

17 Association in Java class MailServer { class MailItem { Set messages; public MailServer() { messages = new HashSet(); public int howmanymessages (String who) {... public MailItem getnextmailitem (String who) {... public void post(mailitem item) {... 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 Grundbegreber fra objektorienteret design.17

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 Grundbegreber fra objektorienteret design.18

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 Truck 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 Grundbegreber fra objektorienteret design.19

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 is-a A Intension(B) Intension(A) B Extension(B) Extension(A) Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.20

21 Specialization in UML General concept LendableItem lend(l: borrower) return() isavalable() Special concepts Book author() publisher() ISBN() Video producer() format() playingtime() Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.21

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 Grundbegreber fra objektorienteret design.22

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

24 Systematics in OOP Modelling 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 Grundbegreber fra objektorienteret design.24

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

26 Interfacebegrebet Interfaces, hvorfor 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 Grundbegreber fra objektorienteret design.26

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

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

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 Grundbegreber fra objektorienteret design.29

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 Grundbegreber fra objektorienteret design.30

31 Mange-til-mange relation ADT interface Specifikation * 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 CDT (abstrakt) klasse * Implementation 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 Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.31

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

33 Typehierarki Subtyper i Java ( ) 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 T 2 T 1, hviss T 1 og T 2 er defineret på en af følgende tre måder: class T 2 extends T 1 {... class T 2 implements T 1 {... interface T 2 extends T 1 {... extends udtrykker en generaliserings- / specialiseringsrelation implements udtrykker en abstraktions- / konkretiseringsrelation Subtype Relationer Såvel specialisering som konkretisering danner subtype Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.33

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

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 Grundbegreber fra objektorienteret design.36

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 Grundbegreber fra objektorienteret design.37

38 Rollebaseret design - motivation Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.38

39 Rollebaseret design - struktur Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.39

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 Grundbegreber fra objektorienteret design.40

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 Grundbegreber fra objektorienteret design.41

42 Design med komposition frem for arv Inheritance considered harmful

43 Faktorisering af funktioner class Computation { void method1(...) { //... computestep1(); computestep2(); computestep3(); //... void method2(...) { //... computestep1(); computestep2(); computestep3(); //... class FactorizedComputation { void computeall(...) { computestep1(); computestep2(); computestep3(); void method1(...) { //... computeall(); //... void method2(...) { //... computeall(); //... Kun brugbar når koden ligger inden for samme klasse! Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.43

44 Faktorisering ved arv class ComputationA { void method1(...) { //... computestep1(); computestep2(); computestep3(); //... class ComputationB { void method2(...) { //... computestep1(); computestep2(); computestep3(); //... class Common { void computeall(...) { computestep1(); computestep2(); computestep3(); class ComputationA extends Common { void method1(...) { //... computeall(); //... class ComputationB extends Common { void method2(...) { //... computeall(); //... Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.44

45 Faktorisering ved delegering class ComputationA { void method1(...) { //... computestep1(); computestep2(); computestep3(); //... class ComputationB { void method2(...) { //... computestep1(); computestep2(); computestep3(); //... class Helper { void computeall(...) { computestep1(); computestep2(); computestep3(); class ComputationA { Helper helper; void method1(...) { //... helper.computeall(); //... class ComputationB { Helper helper; void method2(...) { //... helper.computeall(); //... Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.45

46 Faktorisering, arv vs. delegering Arv Delegering Cryptomathic, F05 Designmønstre Grundbegreber fra objektorienteret design.46

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 Grundbegreber fra objektorienteret design.47