Akronymer CD5130 OOP, fk Software Design Patterns Object-Oriented Analys and Design: (OOAD) Object-Oriented Programming: (OOP) Software design Patterns: (SDP) Gang of Four: (GoF) Graphic User Interface (GUI) Object-Oriented Languages (OOL) Mjukvarumönster Software Design Patterns (sv. Mjukvarumönster) En beprövad och testad lösning till ett vanligt förekommande design problem. Mjukvarumönster Syfte Fånga designerfarenheter från experter Återanvända framgångsrika lösningar till problem Brygga mellan OOAD och OOP OOAD SDP OOP Mjukvarumönster, forts Resultat Hög grad av återanvändning Kunskap Implementation Eleganta system Väl beprövade Flexibla Mjukvarumönster, forts Lösning Abstrahera, abstrahera och abstrahera Beskrivning av problem i naturliga språk Lösning till problemet i naturligt språk med hjälp av OOAD (tex. UML) Mösterkataloger och mönsterspråk
Motivation OOD-metoder betonar design-notationer Bra för specifikationer och dokument OOD är mer än att rita diagram Rita bra bra OOD OOD kräver stor erfarenhet Minst lika viktig som syntax Motivation, forts Återanvända en design är kraftfullast Matcha problemet med designerfarenhet Baserad på beprövad teknik. Kopplar samman utvecklare och administratörer (chefer). Ett mjukvarumönster skall kunna appliceras miljoner gånger utan att vara lika. Christofer Alexander (1979) Historik Christofer Alexander The Timeless Way of Buiding (1979) A Pattern Language (1979) The Oregon Experiment (1988) Mjukvarumönster OOPSLA (1987) The Hillside Group (1993) PLoP (1994) GoF (1995) The Gang of Four Erich Gamma, Richard Helm, Ralp Johnson och John Vlissides Författare till vad som kommit att bli en bibel för SDP Design Patterns Elements of Reusable Object- Oriented Software GoF fick 1998 mottaga Dr Dobbs Journal s: Exellence in Programming Awards. För sitt framgångsrika arbete med SDP. Vad är ett mjukvarumönster? Ett mjukvarumönster beskriver en lösning på ett generellt återkommande problem. Klasser måste arbeta tillsammans. En ensam klass är sällan tillräcklig Mjukvarumönster har ofta en relativt hög abstraktions nivå. Definition av mjukvarumönster En beskrivning av kommunicerande klasser och/eller objekt som har ordnats samman till att lösa ett generellt och återkommande designproblem.
Att studera mjukvarumönster Ett effektivt sätt att lära sig OOD Ta del av experters erfarenheter vad gäller design problem I mer utsträckning en konst än en vetenskap Det krävs Erfarenhet av OO Kreativitet Vad består ett mjukvarumönster av? Mönstrets namn Att ha ett namn som speglar mönstrets funktion är det viktigaste av allt. Problemet Lösningen Konsekvenserna Exempel: MVC-metoden MVC är ett ramverk för utveckling av GUI s Ett konkret exempel där flera mjukvarumönster tillämpas. MVC-metoden, forts En vy återspeglar ett tillstånd i modellen. Modellen känner dock ej till vyn. Varför då? Model A=10 B=20 C=15 User input Control View Visual output A B C 10 20 15 MVC-metoden, forts Hur talar modellen om för vyn/vyerna att den/de skall uppdateras? View1 MVC-metoden, forts Denna design skiljer vyer och modeller åt. Samma idé kan användas för att lösa ett mer generellt problem Model View2 View3 The Observer Särskilj objekt på ett sätt så att förändring i ett av dem påverkar ett ospecificerat antal andra objekt, utan att det förändrande objektet behöver ha en aning om några detaljer om de andra objekten.
MVC-metoden, forts Relationen mellan kontrollanten och vyn är ett annat exempel på hur ett mjukvarumönster kan användas. MVC tillåter förändring av hur vyn svarar på användarindata utan att vyn behöver ändras. Svarsalgoritmen kapslas in i ett kontrollantobjekt En vy har en medlemsvariable som är någon slags kontrollant. En vys kontrollant kan t.o.m förändras under runtime. MVC-metoden, forts Samma idé kan användas för att lösa ett mer generellt problem: Strategy Kapslar in var och en i en familj av algoritmer och låter dem vara utbytbara. Tillåter att en algoritm kan varieras utan att påverka den klient som använder den. Klassificering av mjukvarumönster Klassificering enligt GoF Mjukvarumönster kan delas in i olika kategorier. Detta görs med avseende på deras huvudsakliga uppgift. skapande (creational) strukturerande (structural) beteendestyrande (behavioral) Scope Class Object Creational Factory method Abstract factory Builder Prototyp Singleton Purpose Structural Adapter Adapter(object) Bridge Composite Decorator Flyweight Facade Proxy Behavioral Interpreter Template method Chain of responsibillity Command Iterator Mediator Observer State Strategy Visitor Hur beskrivs mjukvarumönster? Räcker en grafisk notation? Hur kom man fram till designen? Vilka beslut måste tas? Vilka alternativ finns? Vilka konkreta exempel finns som visar designen i aktion? En mall för mjukvarumönster Namn och klassificering Syfte Alternativa namn Motivation Användbarhet Deltagare Deltagarnas samarbete
Mall, forts Konsekvenser Implementation Exempelkod Var de har använts förut Besläktade mönster Hur löser mjukvarumönster problem? De hjälper oss att: Hitta de rätta objekten Avgöra objektens finkornighet Specificera objektens interface Specificera objektens implementaion En första och viktig OOD-princip: Programmera mot ett interface, inte mot en implementation Vad är en klasstyp? Har en klass, en eller flera typer? Typ är inte samma sak som arv! Är en typ ett namn på ett interface? Ett interface är en mängd av meddelande mottagare! Kan ett interface delas i delmängder? Är ett interface en subtype om det är en delmängd till ett annat interface? Mekanismer för återanvändning Två vanliga metoder: Klass arv Objektkomposition En andra och viktig OOD-princip: Favorisera objektkomposition framför implementationsarv Objektkomposition, fördelar Bevarar inkapsling Varje klass kan fokusera på en enda sak Mindre klasshierarkier Objekten blir utbytbara Delegering En extrem form av objektkomposition. Arv kan alltid ersättas med delegering. Exempel: delegering av area-funktion Area Window shape 1 Rectangle Width height Area shape->area() return with*height
Parameteriserade typer Ett annat sätt att återanvända funktionalitet En viss typ lämnas ospecificerad i t.e.x en klass eller en funktion: Design för förändring Befintliga system måste enkelt kunna vidareutvecklas Problem En förändring kan påverka många delar av systemet Det finns design mönster som minimerar dessa problem. Vanliga misstag i en design Objekt skapas genom att explicit specificera den vid namn. Exempel: Button *bu= new MotifButton; Klassen beskriver en viss implementation Skapa objekt indirekt. Abstract Factory, Factory Method, Prototype Beroenden av specifika operationer. Mottagaren till en begäran är hårdkodad. Gör det möjligt att skicka en begäran vidare. Chain of Responsibility, Command Beroenden av hårdvara och/eller mjukvara. Svårt att porta systemet till en ny plattform. Design som minimerar pattformsberoenden. Abstract Factory, Bridge Beroenden av objektrepresentationer och implementationer. Klienter vet hur ett objekt är representerat. Göm denna information för klienter. Abstract Factory, Bridge, Memento, Proxy
Algoritmberoenden. För stark koppling mellan klasser/objekt. Algoritmer förändras ofta. Isolera sådana algoritmer i egna objekt. Builder, Iterator, Strategy, Template Method, Visitor Svårt att förändra/återanvända klasser. Använd tekniker som ger lösa kopplingar. Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer Utöka funktionalitet genom arv. Kräver djup förståelse av överklasser. Föredra komposition eller delegering. Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy Omöjligt att påverka eller förändra vissa klasser som man inte äger (t.ex. inköpta klassbibliotek). Källkod saknas liksom viss funktionalitet. Det finns mönster som medger en viss modifikation av sådana klasser. Adapter, Decorator, Visitor Att tillåta variation En del av styrkan med mjukvarumönster är: Vissa egenskaper kan varieras i systemet. Resultaten blir flexibla och återanvändbara. Exempel på mjukvarumönster Adapter (A.K.A Wrapper) Syfte: Att konvertera interface hos en klass till ett annat så att inkompatibla klasser kan arbeta tillsammans Exempel: Grafikeditor. Grundläggande klasser: linje cirkel, polygon och text Abstraktion: Grafiska objekt kan manipuleras av användaren och rita sig själva.
Adapter Design Adapter, forts Editor Circle * Shape BoundingBox() CreateManipulator() Text TextView GetExtent() GetOrigin() Hur kan TextView återanvändas utav Grafikeditorn Betrakta två lösningar Klassversionen av Adapter Objektversionen av Adapter BoundingBox() BoundingBox() CreateManipulator() CreateManipulator() Klassadapter En generell klassadapter: Objektadapter En generell objektadapter Client Target Adaptee Client Target Adaptee Request SpecificRequest Request SpecificRequest adaptee Adapter Request SpecificRequest() Adapter Request adaptee->specificrequest() Exempelkod: Adapter Exempel: Klassadapter class Shape { public: Shape(); virtual void Boundingbox(Point &tl, Point &br); virtual Manipulator *CreateManipulator() const; }; class TextView { public: TextView(); void GetOrigin(Coord &x, Coord &y); void GetExtent(Coord &width, Coord &height) const; virtual bool IsEmpty() const; }; class Text : public Shape, private TextView{ public: Text(); virtual void Boundingbox(Point &tl, Point &br); virtual Manipulator *CreateManipulator() const; virtual bool IsEmpty() const; }; void Text::BoundingBox(Point &tl, Point &br) { Coord top, left, width, height; GetOrigin(top,left); GetExtent(width,height); tr = Point(top,left); bl = Point(top+height, left+width); }
Exempel: Objektadapter class Text : public Shape { protected: TextView *textview; public: Text(TextView *tv): textview(tv) {}; virtual void Boundingbox(Point &tl, Point &br); virtual Manipulator *CreateManipulator() const; virtual bool IsEmpty() const; }; void Text::BoundingBox(Point &tl, Point &br) { Coord top, left, width, height; textview->getorigin(top,left); textview->getextent(width,height); tr = Point(top,left); bl = Point(top+height, left+width); } Adapter, konsekvenser Klassadapter Kan endast komma åt funktionalitet i en klass. Metoder kan lätt skuggas. Introducerar endast ett objekt. Ingen extra kostnad för pekaranrop Objektadapter Kan komma åt funktionalitet i en hel klasshierarki. Svårt att skugga funktionalitet. Kräver ofta något större ansträngning att skriva än klassadapter. Objektadapter vs. klassadapter Vilken är att föredra? Objektadaptern är mer flexibel Referensen till adaptee kan ändras under exekvering. Systemkrav för mjukvarumönster Inga speciella verktyg krävs. En kompilator för ett OOL T.ex. C++, Java, Ada95, Smalltalk I mjukvarumönster utnyttjas förutom objekt och klasser Arv Polymorfism Det underlättar om språket stödjer detta. Nackdelar med mjukvarumönster När skall man inte använda mjukvarumönster? Oftast åstadkoms flexibilitet genom att ett nytt mellanliggande element adderas till designen. Kan göra designen mer komplicerad Ge prestanda förluster Studera avsnittet konsekvenser i mjukvarumönstrets beskrivning för fullständig förståelse om de nackdelar som associeras med mjukvarumönstret. Relaterade termer Pattern Languages Comosite Patterns Anti-Patterns Frameworks Component Software
Slutsatser Mjukvarumönster ger bland annat: Effektiv design Ökad förståelse Gemensamt vokabulär Stabila system God återvinning Automatisering Referenser Böcker Design Patterns Elements of Reusable Objekt-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1995 Pattern-Oriented Software Archidecture a system of Patterns, Buschmann et. Al Analysis Patterns Reusable Object Models, Martin Fowler, 1997