Desig möster
Möster Sigleto Moostate Null object Factory Composite Observer Abstract server Adapter Bridge Proxy
Sigleto Preseterades reda Exempel: objekt med kofiguratios data Avädig: Cofig.getIstace(). getworkigdirectory() class Cofig{ private static cofig=ull; private Directory wdir=ull;... private Cofig(){...}... public Directory getworkigdirectory(){...}... public static Cofig getistace(){ if (cofig==ull) cofig=ew Cofig(); retur cofig; }
Sigleto (multi-trådig) E multi-trådad variat preseterades också public static Cofig getistace(){ if ( cofig==ull ){ sychroized(cofig.class){ if ( cofig==ull ) cofig=ew Cofig(); } } retur cofig; }... }
Sigleto (multi-trådig) Me detta fukar ite Kode på föregåede slide ka översättas till ågot i stil med -> För första tråde fugerar det bra E adra tråd ka returera ett ickeiitialiserat objekt public static Cofig getistace(){ if ( cofig==ull ){ sychroized(cofig.class){ if ( cofig==ull ) cofig= Oiitialiserat objekt ; cofig.costructor(); } } retur cofig; }... }
Sigleto (multi-trådig) Det rätta sättet är att göra public static sychroized Cofig getistace(){ if ( cofig == ull ){ cofig = ew Cofig(); } retur cofig; }... }
Fördelar med sigleto Cross platform Med e lämplig middleware (t. ex.) RMI ka ett sigleto objekt fugera över olika JVMs och flera datorer Fugerar för alla klasser. E klass görs till sigleto geom att göra kostruktor privat och addera e statisk metod Ka skapas geom edärvig E subklass ka bli e sigleto Lat evaluerig Om e sigleto objekt aldrig aväds så skapas det ite
Nackdelar med sigleto Destruktio är ite defiierad Det fis ite ågot bra sätt att förstöra ett sigleto objekt. Gäller speciellt i språk som ite har garbage collectio (t. ex C++) Egeskape ärvs ite E subklass av ett sigleto objekt är ite ödvädigtvis ett sigleto objekt Sabbhet E extra if sats behövs för att komma åt istase Ite trasparet Avädare måste veta att de aväder ett sigleto objekt
Moostate Alterativ till Sigleto möstret class Cofig{ private static Directory wdir=ull;... public Cofig(){...}... public Directory getworkigdirectory(){...}... } Alla variabler deklareras som static me ige av metodera är defiierade som static
Moostate Ett moostate objekt ka avädas som ett valigt objekt Cofig cofig= ew Cofig(); dir=cofig.getworkigdirectory(); Data delas dock mella dom olika istasera Alla variabler var ju deklarerade som static
Fördelar med moostate Trasparet Avädare behöver ite bry sej om att objektet är ett moostate objekt Nedärvig Subklasser av moostate klasser är också moostate klasser. Alla delar samma static variabler Polymorfism Eftersom ige metod är static, ka metoder omdefiieras i subklasser Väldefiierad kostruktio och destruktio Eftersom variablera är static
Nackdelar med Moostate Ige koverterig E klass ka ite bli koverterad till e moostate geom ärvig Effektivitet Skapade av objekt kräver mie och är lågsamt. Dessutom aväds ite data i objekte. Variablera i e moostate klass tar alltid upp plats, också om iga moostate objekt behövs Lokal till plattforme. Ett moostate objekt ka ite fås att fugera över olika JVM istaser
Null object Följade typ av kod är mycket valig Employee e =Database.getEmployee( Bob ); if ( e!=ull && e.istimetopay()){ e.pay(); } Fugerar pga. short-circuit evaluerig av logiska uttryck adra dele av uttrycket evalueras bara om de första evalueras till sat Lätt att ma glömmer att checka för ull
Null object Kude aväda exceptios i stället Me try/catch block ka bli äu besvärligare att aväda Svårt att få att fugera med existerade kod Database <<it erface>> Employee Null Employee EmployeeImpemetatio
Null object Kode frå exemplet ka u ädras till Employee e =Database.getEmployee( Bob ); if (e.istimetopay()){ e.pay(); } Mera kosistet då Database.getEmployee alltid returerar ett objekt
Null object Employee grässittet ka defiieras som: iterface Employee{ public boolea istimetopay(date date); public void pay(); } public static fial Emplyee NULL = ew Employee(){ public boolea istimetopay(date date){ retur false;} public void pay(){} }; Aoym klass garaterar att det fis bara ett NULL objekt
Null object Ka u aväda if (e ==Employee.NULL ){... Fördelar Giltiga objekt retureras alltid Iga NullPoiterExceptios
Factory Depedecy iversio priciple (DIP) går ut på att ma ska föredra beroede till edast abstrakta klasser/grässitt Circle c=ew Circle(origi, 1); List<Comparable> t= ew LikedList<Comparable>(); Alltid då ma skapar objekt med ew så itroducerar ma ett beroede på kokreta klasser Bryter mot DIP Ofta iget problem om klasse ma skapar objekt av ite ädras (t. ex. Strig) I system som håller på att utveckla ka det bli problem
Factory Perso exempel Flera olika subklasser Rätt subklass ska väljas baserat på vissa kriterier Cetralisera skapade av objekt istaser Factory Perso p= makeperso( Aa, 14); public Perso makeperso(strig ame, it age){ if(age<13) retur ew Child(ame, age); else if (age<20) retur ew TeeAger(ame, age); else retur ew Adult(ame,age); }
Factory E metod som alltid skapar objekte på rätt sätt Var ska metode placeras? I basklasse, Perso p= Perso.makePerso(ame, age); Basklasse behöver då käa till alla subklasser Ege factory klass Perso p= PersoFactory.makePerso(am,age); Oftast ett bättre val
Polymorfa factories Exempel: javas iteratorer för behållare Varje behållare implemeterar Iterable grässittet Varje behållare är asvarig att returera e passade iterator som uppfyller Iterator grässittet Allt ma behöver veta om ett behållarobjekt är att det implemeterar Iterable grässittet
Polymorfa factories <<iterface>> It erable Iterable<T> itr = ew ArrayList<T>; ArrayList LikedList EgeBehållare <<it erface>> Iterator Iterator<T> it=itr.iterator(); while(it.hasnext()){...it.ext(); AbstractList.Itr EgeIterator
Factories (Factory method) Product <<iterface>> Creat or CocreteProduct1 Cocre tepro duct2 CocreteCreator1 CocreteCreator2
Factory Exempel ur boke
Abstract Factory E beskrivig över tillverkare av objekt Aväds för att beskriva tillverkare av e familj av produkter som hör ihop Defiierar ett grässitt som alla tillverkare måste följa Exempel: Lokaliserig av program persoligt id datum klockslag represetatioe ser olika ut i olika läder
Abstract factory public abstract class PersoId{... } public abstract class Date{... } public class FiladTimeOfDay exteds TimeOfDay{... } public abstract class TimeOfDay{... }
Abstract factory public iterface FormatFactory{ public PersoId createperoid(...); public Date createdate(...); public TimeOfDay createtimeofday(...); } public class FiladFormatFactory implemets FormatFactory{ public PersoId createperoid(...){...} public Date createdate(...){...} public TimeOfDay createtimeofday(...){...}
Abstract factory Avädare behöver u ite bry sej om hur dom olika objekte skapas Geerellt grässitt för skapadet av objekt Ofta avät för att ge ett program aa look-ad-feel Lätt at byta e familj uppsättig mot e aa Byt factory E ackdel är att det ka kräva e del arbete att lägga till e produkt
Abstract factory - geerellt <<it erface>> AbstractFact ory CocreteFactory1 CocreteFac tory2 <<iterface>> AsbtractProductA Product A1 ProductA2 <<iterface>> Asbt ractp roductb ProductB1 ProductB2
Composite Haterig av hierarkier av objekt Exempel filsystem: : Directory : Directory : Directory : File : File : File : Directory : File
Composite Tre kategorier av operatioer Operatioer som alla oder har gemesamt Operatioer som gäller för förgreigsoder Operatioer som gäller för löv För filsystem Byta am, ädra ägare, rättigheter Lägga till och ta bort filer i e katalog, lista katalogiehåll läsa och skriva iehåll
Composite Försök till filsystem desig Node setnam e() getnam e() 0..* File readcotet() writecotet() Directory addnode() rem ovenode() getchi ldre()
Composite Edast kataloger ka ha barobjekt De här desige har små problem, t. ex: Då ma vill gå igeom strukture if (thenode istaceof Directory){ Directory dir = (Directory) thenode; Iterator<Node> childre = dir.getchildre(); while (childre.hasnext()){... } }
Composite Ma borde alltså defiiera barhaterigsfuktioer reda i basklasse Node Filera kommer att påtvigas Directory operatioer Node setname() getname() addnode() rem ovenode() opame() getchildre() 0..* Föreklar kode File readcotet() writecotet() Directory addnode() removenode() getchildre()
Composite Föreklar kode Iterator<Node> childre =thenode.getchildre(); while ( childre.hasnext()){ //... File objekt i java represeterar också både filer och kataloger Har e metod listfiles Ka eklare lägga till ya typer av subklasser
Composite Compoet operatio() add() remove() getchildre() 0..* Leaf Composite
Composite Exempel Se boke
Observer Ursprug i Smalltalk Model/View När ett objekttillståd uppdateras fis det ett atal objekt som måste få reda på detta och i si tur göra ågot Observer ett objekt som ka observera ett aat objekts tillstådädrigar Adra am Model/View, publish/subscribe, documet/view
Observer - textredigerare Direkta beroede mella olika kompoeter ite bra Svårt att sätta till ya kompoeter Svårt att hatera beroede : Tex twidow : TextDocumet : WordCout er : SpellChec ker
Observer <<iterface>> Subject otify() attach() detach() <<iterface>> Observer update() TextDocumet readtextdata() writetextdata() SpellChecker TextW idow W ordcouter
Observer :Te xtdocum et :SpellChecker : TextWidow : WordCouter outer user 1: attach 2: attach 3: attach 4: writetextdat a 5: update 6: update 7: update
Observer Ekelriktat beroede textobjekte behöver ite hålla reda på vem som observerar dem Nya observatörer ka ekelt läggas till Ka ite heller skicka specialiformatio för specifika observatörer Ka ge prestadaproblem med måga observatörer Variater Data ka skickas med update metode eller ite
Observer Exempel ur boke
Abstract server Switch Light turo() turoff() Desige strider mot två desigpriciper Depedecy Iversio priciple Policy beror på e kokret klass Ope-closed priciple Måste släpa med Light överallt vi behöver e Switch
Abstract server Kude kaske skapa e subklass av Switch för att reglera adra saker Switch Light turo() turoff() FaSwitch Fa turo() turoff()
Abstract server Abstract server möstret Satisfierar DIP och OCP Switch <<iterface>> Switchable turo() turoff() Light turo() turoff() Notera att grässittet hör logiskt till kliete Gör iget uta e Switchable grässitt
Adapter I föregåede exempel fis det potetiellt problem med Sigle-Reposibility Priciple Budit ihop klasser Light och Switchable Light kaske reda fis i ågot bibliotek och ka ite ädras Light kaske ite ka ärva av Switchable Problemet ka lösas med e adapter
Adapter Sätt i e adapter mella Switchable och Light Switch <<iterface>> Switchable turo() turoff() LightAdapter turo() turoff() Light turo() turoff() All problems i computer sciece ca be solved by aother level of idirectio Butler Lampso
Adapter - exempel Exempel i boke
Adapter geerell ACliet Target operatio() Adapter a : Adaptee operatio() Adaptee otheroperatio() a.otheroperatio()
Bridge Att frigöra e abstraktio frå si implemetatio så att båda ka variera oberoede Exempel Modem Modem DialModem DedicatedModem HayesDialModem EriesDialModem HayesDedModem EriesDedModem
Bridge Om ma sätter till e y typ av modem kräver det två ya klasser Två frihetsgrader här
Bridge geerell Abstractio <<iterface>> Im plemet or Refi edabtract io 1 RefiedAbstractio2 CocreteImplemetor1 CocreteImplemetor2
Bridge Exempel ur boke
Bridge Ka avädas då: Ma vill dyamiskt kua byta ut implemeterig för e avädare Avädare och implemeterigar ska kua variera oberoede av varadra Ma vill aväda samma implemeterigsobjekt för flera avädare uta att de vet om det Ma vill på ett tydligt sätt separera implemetatio och grässitt
Bridge Separera avädargrässitt frå implemetatio Implemeterigar ka bytas ut dyamiskt Ka vara svårt att hitta de rätta grässitte Fuktioalitet som borde lämas flexibel åt implemetatioe ka ha låsts i abstraktiosdele, och tvärtom
Proxy Aropa e ställföreträdare istället för att direkt aropa objektet Orsaker: Objektet som ma vill komma åt fis på e aa dator. Java aväder fjärrproxy för att implemetera fjärrarop med RMI Objektet är dyrt att aväda. E lat ställföreträdare (virtual proxy) optimerar åtkomste geom att till exempel geom att till exempel fördröja skapadet av objektet Objektet behöver åtkomstskydd. E skyddsställföreträdare (protectio proxy) reglera åtkomste Objektet förses med e smart referes/pekare som gör ågot extra är objektet aväds. Till exempel räkar aktiva refereser.
Proxy - exempel E proxy ska oftast kua avädas som origial objektet Cliet <<iterface>> Image getname() draw() ImageProxy i : Im agefile getnam e() draw() Im agefile getname() draw()
Proxy - exempel public class ImageFile implemets Image{ public iterface Image{ Strig getname(); void draw(); } } public ImageFile(Strig ame){...} public Strig getname(){...} public void draw(){...}
Proxy -exempel class ImageProxy implemets Image{ private Strig fname; private ImageFile image; public ImageProxy(Strig ame){ fame=name; } public void draw(){ if ( image==ull) image=ew ImageFile(ame); image.draw(); }
Proxy Proxy objektet måste ha ågo kotakt med det riktiga objektet Här referes Fjärrproxy ikapslar kommuikatio över ätverk Ofta opraktiskt att avädare som vill komma åt orgialtjäste måste behöva käa till proxy Factory möster ka avädas E ackdel med Proxy är att de ka dölja extra kostad som associeras med åtkomst Nätverkstrafik