Szoftvertechnolgia s Grafikus Felhasznli Fellet Tervezse Tervezsi mintk

Szoftvertechnológia és Grafikus Felhasználói Felület Tervezése Tervezési minták bevezetés Creational Patterns Factory, Abstract Factory, Io. C Singleton Prototype, Builder http: //users. nik. uni-obuda. hu/prog 4/ 1

Legacy (=rossz=nem kezelhető) megoldás • „It works, so what? ” + Mi fog változni? Majd az architect tudja… • Mi a fontosabb? – Könnyen olvasható, karbantartható, újrahasználható? – A megírás sebessége, kódhossz, futtatás sebessége? 2

S = Single Responsibility • Minden osztály egy dologért felelős ( do one thing and do it well) • Ha nem követjük, akkor … – Átláthatatlan „Big Ball Of Mud” és „Spagetthi code” – Kezelhetetlen, gigászi méretű, mindentudó „God Object”-ek – Mindenért felelős alkalmazások és szolgáltatások – Alkalmazás szinten sajnos egyre kevésbé követik (Winamp, Chrome, Systemd, Moodle) – A korábbi csillagmozgató metódus tipikus ROSSZ példa – KEZELHETETLEN, ROSSZ KÓD 3

O = Open / Closed • Open for extension, Closed for modification • Minden osztály EGYSZERRE felhasználható és leszármazottakkal értelmesen bővíthető, ezáltal a működése befolyásolható • Ha nem követjük, akkor … – Értelmetlen, lekövethetetlen osztályhierarchiák – Nehezen vagy egyáltalán nem bővíthető hierarchiák – Tipikus tünet: az új leszármazott megírásakor módosítani kell az ősosztályt IS – Ez TILOS, hiszen az ősosztályra többnyire nincs rálátásunk vagy módosítási lehetőségünk (framework/library esetén főleg) – Tipikus tünet: egy kis funkció hozzáadásához több osztályt kell hozzáadni ugyanabban a hierarchiában – Egy hierarchiába több tényezőt is összezárunk – KEZELHETETLEN, ROSSZ KÓD 4

L = Liskov substitutable • Őspéldány helyett utódpéldány mindig legyen használható – Ez befolyásolhatja a működést, de nem teszi tönkre – Részben compiler supported, hiszen részben OOP elv (type polymorphism / covariance / contravariance) – Ha van egy kliensosztályunk, ami úgy tudja, hogy egy konkrét X osztállyal dolgozik, nem szabad elszállnia attól, ha X helyett annak Y utódját kapja meg helyette • Paraméter – A kliensosztály úgy tudja, az X osztály [5. . 10] értékeket fogad – Az Y osztály tágabb intervallumot fogadhat, kisebbet nem • Eredmény – A kliensosztály úgy tudja, az X osztály [5. . 10] értékeket ad vissza – Az Y osztály tágabb intervallumot nem adhat vissza, kisebbet igen • Ha nem követjük, akkor … KEZELHETETLEN, ROSSZ KÓD 5

I = Interface segregation • Sok kicsi interfész jobb, mint egy nagy – A nagyobb interfész mindig összeállítható a kisebbekből • Ha nem követjük, akkor … – Átláthatatlan „Big Ball Of Mud” és „Spagetthi code” – Kezelhetetlen, gigászi méretű, feldarabolhatatlan interfészek – Tipikus tünet: a funkciók egy részének implementálása a cél egy osztályban, de a túl nagy interfész miatt sok az üres metódus – Tipikus tünet: az interfészhez több implementáló osztály jön létre a kód legkülönbözőbb helyein, és ezeket a külön-külön funkcionalitásoknak megfelelően külön-külön helyen használjuk, mindenhol más-más metódusokat – KEZELHETETLEN, ROSSZ KÓD 6

D = Dependency Inversion • A függőségeket ne az őket felhasználó osztály hozza létre – Helyette kívülről adjuk meg a példányokat – Ez nem azt jelenti, hogy egy osztályban tilos a new() – A service függőségek NE konkrét implementáló osztályok, hanem interfészek/abstract osztályok legyenek • A konkrét példány megadására több módszer – Dependency Injection (prog 3) – Factory patterns (prog 4) – Inversion of Control (Io. C) containers (prog 4) • Ha nem követjük, akkor … – Egymástól szorosan függő osztályok végtelen láncolata – Lehetetlen a normális modularizálás és rétegzés – Lehetetlen a normális kód újrahasznosítás – KEZELHETETLEN, ROSSZ KÓD 7

OO alapelvek (ismétlés) • SOLID – Single Responsibility – Open for extension, Closed for modification (class is both open and closed / virtual methods) – Liskov substitution (replaceable with subtypes) – Interface Segregation (small specific interfaces) – Dependency Inversion (depend on abstractions loose coupling) • DRY = Don’t Repeat Yourself • DDD = Domain Driven Design 8

SOLID Star. Mover STAR MOVE (Direction) SUBJECT DISPLAY (X, Y, Char) MOVER LOGIC CONSOLE MOVER ENVIRONMENT / CONTEXT interface IComplex : IDisplayable, IMoveable { class Star : Icomplex public Mover (IComplex subject) class Console. Mover : Mover } 9

Gang of Four + Források Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides "A must have book for any developer" "Beyond Comparison " "Still the best " "You've written a million lines of code, Now. . . do it better !" Horváth Rudolf: Common Design Patterns Aniruddha Chakrabarti: Design Patterns (Go. F) in. NET http: //dofactory. net/design-patterns 10

Egyéb olvasnivalók a témában • Michael Feathers: Working Effectively with Legacy Code • Joshua Kerievsky: Refactoring to Patterns • Martin Fowler: Refactoring (a. k. a. The Refactoring Bible) 11

Öröklés vs kompozíció • Favor object composition over class inheritance. • Öröklés: fordítási időben definiált/nem módosítható + Könnyebben érthető/módosítható újrahasznosítás esetén - Futásidőben nem módosítható - Az örökölt funkciók sem módosíthatóak futásidőben - Az ősosztály sokszor túlságosan definiálja az utódosztályokat • Kompozíció: futásidőben definiált/változtatható + Futásidőben minden objektum lecserélhető azonos funkcionalitású vagy leszármazott típusú példányra + Jóval kevesebb függőség + Sokkal könnyebben darabolhatóak az osztályok feladatokra; kisebb és specifikusabb osztályok - Nehezebb a rendszer / függések / metódus hívások megértése és lekövetése 12

Alapelvek • Maximize class reuse / possibility for class reuse – Practical vs Theoretical reuse • Anticipating structural changes – Új igényekre / változtatásokra előre gondoljunk LEHETETLEN – MINDEN változhat, minden változni fog valamikor!!! – A tervezési minták bizonyos tényezők/körülmények módosítására készítik fel a rendszert bizonyos szabályok / javaslatok segítségével • Future expectations – A Common Design Vocabulary – A Documentation and Learning Aid – A Target for Refactoring • Egyes minták már „outdated” szintűek a nyelvi feature-ök miatt – Pl. Lisp/Dylan, de hétköznapi nyelvekben is (pl. Iterator) 13

Egy tervezési minta részei 1. Pattern név (Name, Classification) – Valamilyen egyedi azonosító, ami alapján könnyen tudunk hivatkozni a tervezési mintára (és következményeire) – Ennek segítségével elérjük az egyik fontos elvárást: COMMON VOCABULARY (kisebb korlátokkal) 2. Problémakör (Intent, Motivation, Applicability) – Leírja azt a körülményt (kontexust), amire a pattern választ ad 3. Megoldás (Structure, Participants, Collaborations) – Leírja a javasolt megoldás részeit: osztályok, kapcsolatok, tagok, felelősségi körök, együttműködő felek 4. Következmények (Consequences, Related patterns) – A pattern használatának pozitív és negatív hozományai 5. Implementáció – A könyvnek nem része, de nálunk igenis szó lesz róla 14

Tervezési minták alkalmazása • „By-The-Book” – Újratervezés / módosítás / előre tervezés esetén vizsgáljuk meg a komponenseket, azonosítsuk a változó/lényeges tényezőket – Ehhez válasszuk ki az illeszkedő tervezési mintákat – Ellenőrizzük a célokat/következményeket, és a kapcsolódó tervezési mintákat, majd döntés: melyiket használjuk • Gyakorlatban – Fejlesztés közben nem figyelünk a rossz jelekre (“code smells”) – Azután a dolgok felrobbannak, és hónapokig/évekig szenvedünk a rosszul tervezett és megírt kóddal – Refaktorálás „MAJD” – Mindegyik következő projektben kicsit jobb lesz, folyamatosan közeledünk az ideális megoldáshoz (újra felfedezzük a kereket) – Majd egy hasonló óra/tanfolyam/cikk során olvasunk a tervezési mintákról, és ekkor „ÍGY kellett volna csinálnom!” 15

Go. F minták Purpose Design pattern Short description Creational Factory method Get. Instance( instance. Type) Abstract factory Több Factory, Get. Instance(factory, instance. Type) vagy Get. Instance(instance. Type) Singleton Egyetlen példány használata (. Default /. Current) Prototype Deep copy létrehozása (. Clone()) Builder Példány létrehozása több lépés/rész/folyamat segítségével 16

Purpose Design pattern Short description Behavioral Iterator foreach () { } Chain of resp. Több műveletvégző segítségével egy művelet végrehajtása Visitor Végrehajtó és tárgy szétválasztása – több látogató/látogatott: IVisitor. Visit(IVisitor. Acceptor) IVisitor. Accept(IVisitor) Command Végrehajtási kérés/utasítás objektumba ágyazása Observer Hívó és hívott szétválasztása (események segítségével ) Mediator Hívó és hívott teljes szétválasztása (központi vezérlővel) State Státusz osztályok, amik a státuszváltozásokat vezérlik Interpreter Tetszőleges bemenet tetszőleges kimenetté konvertálása Memento Előző tartalom visszaállítása Strategy Teljes implementáció/módszer a leszármazottakban Absztrakt ősosztálytól függés a konstruktorban Dependency injection (via Abstract) Template method Egyes lépések definiálása a leszármazottakban Virtuális metódusok , Metódus polimorfizmus 17

Purpose Design pattern Short description Structural Adapter Meglévő osztály/interfész használata egy másik interfész/osztály helyett Wrapper class Bridge Nagy hierarchia felbontása két hierarchiára, és kompozíció segítségével összekapcsoljuk Dependency injection Composite Olyan fa adatszerkezet , ahol a levéllel, részfával, és az egész fával ugyanazok a műveletek lehetségesek Flyweight Memóriahasználat csökkenése megosztott belső paraméterekkel, singleton referenciákkal , on-thefly property számolással és instance pooling segítségével Façade Front controller, belső osztályok elrejtése, hívások egyszerűsítése Proxy Transparent Façade ÉS extra funkciók/ellenőrzések elvégzése az eredeti előtt/után Decorator Funkciók tetszőleges összeállítása kompozíció 18

Creational Design Patterns Purpose Scope Creational Structural Behavioral Class Factory method Adapter Interpreter Template method Object Abstract factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 19

Factory method – Validation. Factory (prog 3) Vizsgán a comment-mentes C# kódok + UML diagramok elérhetőek! 20

Factory method – Validation. Factory (prog 3) • A Validator osztály feladata: annak ellenőrzése, hogy a paraméterül kapott objektum minden szabálynak megfelel –e • Ehhez egy IValidation interfészt implementáló osztály Validate metódusát kell meghívnia az összes tulajdonság összes validációs szabályához • Nem tartozik az osztály felelősségi körei közé, hogy tudjon róla: – Konkrétan milyen validációs attribútumok vannak – Melyik attribútumhoz milyen ellenőrző osztályok tartoznak – Melyik ellenőrző osztályt hogyan kell létrehozni • Ezért kiszervezzük az ellenőrző osztály létrehozását egy külön factory osztályba, és így a validator csak az interfészről tud: – var validation = validation. Factory. Get. Validation(custom. Attribute) – validation. Validate(instance, property. Info) 21

Factory method vs Abstract Factory • Alapelv: „S”OLID – Egy üzleti logikát (számítást) elvégző osztály nem feltétlenül tudja (nem akarja tudni), hogy a létrehozandó objektumnak konkrétan milyen függőségei vannak – A függőségei, a létrehozás feltételei meg még kevésbé érdekesek – A létrehozást kiszervezzük egy másik osztályba/metódusba – Factory method: inheritance; Abstract factory: composition • A factory method meghívásakor a konkrét factory-k öröklési láncától függ, hogy pontosan milyen objektum jön létre – Néha a factory method paraméterétől is függhet, hogy pontosan milyen objektum jön létre – Egyetlen factory ősosztály, aminek a leszármazottai felelősek megfelelő típusú példányok létrehozásáért egy osztálycsoport / osztályhierarchia típusaiból 22

Factory method 23

Factory method – dokumentum+kép 24

Factory method – subject 25

Factory method – factories 26

Factory method – meghívás • A Document. Generator nem tudja, konkrétan milyen dokumentumok és képek léteznek, és ezeket hogyan kell létrehozni • A paraméterül adott factory feladata a MEGFELELŐ dokumentum és a MEGFELELŐ kép létrehozása • A factory osztályok öröklési lánca szabja meg a létrehozandó objektumok körét/módját 27

Factory method. NET = Get. Enumerator() • Get. Enumerator() metódus – Minden foreach ciklusnál meghívódik – A gyűjteménynek megfelelő bejárást elvégző implementációt adja vissza 28

Abstract factory • Akár a korábbi példa is lehetne Abstract factory – Img. Factory. Get. Image() + Doc. Factory. Get. Document() – Page. Item item = Item. Factory. Create(”Image/Jpeg”); – Alapelv: több factory együttműködése, a gyakorlatban szinte mindig ez a helyzet (és: „Composition over Inheritance”) – Anti-pattern: Factory-t létrehozó factory… 29

Abstract factory –. NET 30

Abstract factory –. NET 31

Abstract factory –Controls 32

Abstract factory – Factories 33

Abstract factory – Main factory • Rengeteg változat létezik – Paraméter (String, Type, Enum), Static/Nonstatic – Dictionary<Type, Func<bool, IControl>> , Reflexió – Chain of Responsibility tervezési minta a nagy SWITCH helyett (ld. később) – Null eredmény helyett kivétel 34

Main factory/Factory method– String param. • Előny: nem kell pontos hivatkozás a típusra, elég valami azonosító, esetleg IDE supporttal megtámogatható • Hátrány: bonyolult lehet a típus nevének/azonosítójának konkrét ismerete, nincs compiler support, hiba esetén null/exception lekezelése, a SWITCH nagyon hosszúvá válhat 35

Main factory/Factory method– Reflection • Előny: Reflexió = rugalmas Hátrány: nagyon lassú, csak default konstruktort tud hívni • Create. Image( Type img. Type) vagy Create. Image< Img. Type>() vagy Register. Image( Type img. Type, Func<bool, IControl> creator) Hátrány: pontos típusreferencia kell Előny: Compiler support, és legalább a pontos konstruktorhívással nem kell szenvedni • Static. Factory. Create. Image(xxx) Előny: nem kell példányosítani Hátrány: nem lehet mockolni, ami NAGY probléma (ld. Singleton) 36

Main factory/Factory method– ROSSZ módszer 37

Main factory/Factory method– ROSSZ módszer • Enum paraméter – Előny: compiler support – Hátrány: bővítéskor az enum átírandó a hierarchia bővítésekor (új leszármazott osztály esetén) a független enumot módosítani kell Hidden dependency!!! – OPEN/CLOSE VIOLATION, CODE SMELL! 38

Dependency Inversion vs Injection • Dependency Inversion (Inversion of Control) elv: A használt objektum pontos típusa fordítási időben nem ismert, mert azt futási időben, paraméterek/user input/körülmények alapján egy „összeállító” (assembler object) hozza létre • Formái – Dependency injection (Prog 3) Interfész típusú konstruktor paraméter, futásidőben a hívó dönti el, hogy konkrétan milyen példányt ad paraméterül – Factory patterns A létrehozás kiszervezése külső osztályba/metódusba – Io. C container A létrehozás és akár a függőségek létrehozása is legyen teljesen automata, egy központi függőségkezelő modul segítségével – Hidden Io. C (ANTI PATTERN) Az Io. C container rejtett használata, így a konstruktor paraméterek alapján nem látszanak a függőségek 39

Klasszikus (non-inverted) mód 40

Inverted mód 41

Dependency Injection (Lásd előző félév, prog 3, 06. prezentáció) interface IMy. Dependency { string Do. Something(); } class My. Class { private IMy. Dependency dependency; public My. Class(IMy. Dependency dependency) { this. dependency = dependency; } // metódusaiban: dependency. Do. Something() } // használata IMy. Dependency my. Dependency; // értékadás. . . My. Class my. Class = new My. Class(my. Dependency); 42

Abstract factory – Main factory (Lásd korábban, ebben a prezentációban) 43

Io. C container 44

Dependency Inversion vs Injection • A dependency injection mindig az alap – Absztrakcióktól függő, kívülről kapott példánnyal dolgozó megvalósítás nélkül nem használható igazából egy osztály sem – A függőségeket majd létrehozza egy valamilyen komponens… • Dependency Injectiont felhasználó külső koponensek – Factory, Abstract Factory A belé programozott osztályokból tud létrehozni példányokat, a belé programozott módon, függőségeket elrejtve Reflexióval félautomatává tehető, de ha már erre elindulunk… – Io. C container Az (akár ismeretlen! ) osztályokból a példányok és a függőségek létrehozása is lehet teljesen automata (autowire & autoconfig) – Builder (NEM dependency inversion, ld. később) 1 builder 1 konkrét osztályból tud példányt létrehozni, valamilyen lépéssort követve – függőségeken nem változtat 45

Io. C container – valódi példák • DI container / Service Container / Io. C container • MVMM Light Simple. IOC / Unity / Ninject / Auto. FAC Symfony Container / ASP. NET Core DI Container 46

Io. C container – Simple. IOC 47

Io. C container - Simple. IOC 48

Io. C container – Unity 49

Io. C container – NInject 50

Io. C container – Auto. FAC 51

Io. C container – ASP. NET Core, autowire! 52

Io. C container – Symfony container, autowire! 53

Hidden Io. C = Anti-pattern • A név nem 100%-ban elfogadott, sokszor hivatkoznak rá, mint „Service Locator”, de ugyanezt a használják a jó használatra is… • Lényeges különbség: a rejtett használat az Io. C container olyan ROSSZ használata, ahol elrejtjük a függőségeket – Paraméterek helyett az Io. C-t belül használjuk – A kód újra-felhasználást lehetetlenné teszi 54

Hidden Io. C = Anti-pattern • Ilyen Io. C használat helyett constructor vagy method injection • Túl sok típus/paraméter God Object, code smell! 55

Creational Design Patterns Purpose Scope Creational Structural Behavioral Class Factory method Adapter Interpreter Template method Object Abstract factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 56

Singleton class Single { private static$instance; private $singleton. Data; private function__construct() { } public static functionget. Instance() { if(!self: : $instance) self: : $instance = new Single(); return self: : $instance; } public functionget. Singleton. Data() { return $this->singleton. Data; } } public functionsingleton. Operation() { // do whatever } ----------------------------------$my. Singleton = Single: : get. Instance(); $my. Singleton->singleton. Operation(); $my. Singleton->get. Singleton. Data(); 57

Singleton • Pontosan egy példányt akarunk egy osztályból, ami elérhető egy jól ismert ponton keresztül , tipikusan Some. Class. Single. Instance • Azonos funkcionalitás, mint statikus osztály esetén, de – Rendelkezhet ősosztállyal – Implementálhat interfészt – Szerializálható (és máshol is használható paraméterként) – Lehet generikus (C#-ban a static class is, máshol nem mindig) • … Akkor használhatjuk, amikor nem akarjuk unit tesztelni a singleton/statikus függőséget … Vagyis, SOHA? ANTI-PATTERN? • Újabban a singleton nem feltétlenül statikus tag, az Io. C container konfigurálható: always new instance / always same instance / named instance / instance pooling – Ez mockolható, és a visszaadott példány később lehet akár egy leszármazott példány is 58

Singleton –. NET 59

Singleton – C# 60

Singleton – C# 61

Singleton – C# 62

Singleton – C# 63

Singleton – C# • „Almost thread safe” . NET 1 -ben és Java-ban nem volatile kulcsszó …. NET 2 –től ez nem szükséges! • Race condition, „ 13. [Extra for Experts ]”: http: //sce 2. umkc. edu/BIT/burrise/pl/design-patterns/qanda. html • „Reads and writes are regularly reordered by the compiler and runtime system to improve performance ” 64

Creational Design Patterns Purpose Scope Creational Structural Behavioral Class Factory method Adapter Interpreter Template method Object Abstract factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 65

Builder 66

Builder • EGY builder = EGY osztály példányainak létrehozásáért felelős • Egy példány létrehozása több lépésből/részből áll • Egy példány létrehozásához sok (részben opcionális) adat kell, és nem akarunk sok konstruktor-paramétert (opcionális/nevesített paraméterekkel működne, de nagy mennyiségben csúnya) • Nem használhatunk konstruktor paramétereket, ha – A konstruktor hívásakor még nem áll rendelkezésre minden adat – A rész-lépéseket ciklusban kell meghívni – A paraméterek ciklusban jönnek létre – Feltételektől függő paraméterek / lépések túl sok ágú elágazás, ugyanazon típusból példány létrehozás más-más paraméterezéssel 67

Builder – C# 68

Builder – C# 69

Builder – EF fluent API 70

Builder –. NET 71

Builder –. NET 72

Prototype 73

Prototype • Cél: példányok létrehozása másolatként • Amikor fix tartalmú példányaink vannak csak (vagy: Java. Script) • Fontos kérdés: deep copy vs shallow copy a prototype esetén minden másolat DEEP COPY! 74

Prototype 1 – C# 75

Prototype 2 – C# 76

Köszönöm a figyelmet! Tervezési minták bevezetés Creational Patterns Factory, Abstract Factory, Io. C Singleton Prototype, Builder http: //users. nik. uni-obuda. hu/prog 4/ 77