9 - Objektumelvű tervezés

Nagy rendszerek fejlesztési fázisai, fejlesztési módszerek

Fázisok

• Specifikáció
  • Megvalósíthatósági elemzés
  • Követelmény feltárás és elemzés
  • Követelmény specifikáció
  • Követelmény validáció
• Tervezés és implementációű
  • <programozási paradigmák helye>
• Verifikáció és Validáció
  • Tesztelés több fázisban
  • Elvárások teljesítésének bemutatása
• Evolúció
  • Új követelmények feltárása és megvalósítása
  • Felmerülő hibák és hiányosságok pótlása

Fejlesztési módszerek

• Vízesés modell
  • minden lépés az előzőre várva, sorban következik
• Prototípusok
  • horizontális prototípus: interakciós szempontból mutatja be az alkalazást
  • vertikális prototípus: egy finkció(vagy funkciócsoport) részletes megvalósítása
  • hosszútávú (evolutionary prototyping) és bemutatás jellegű (throwaway prototyping) prototípusok is létezhetnek
• Spirális modell
  • kockázatfelmérés alapú
  • mit csináljunk > mik a veszélyek > csináljuk meg > tervezzük meg a következő spirált
• Inkrementális modell
  • minden változat új funkcionalitással bővíti a szoftvert
  • a fázisok rövidek, gyors visszajelzéssel
  • egyes fázisok átfedésben vannak és kihatnak egymásra
• Agilis szoftverfejlesztés
  • folyamatos fejlesztés és kiadás
  • állandó sebesség
  • a fejlesztés jellemzően önszervező
• Scrum
  • futam alapú fejlesztés
  • termékgazda készíti el a teendők listáját (backlog)
  • napi megbeszélések (stand-up meeting) csapatszintten
  • ciklus végén nagyobb megbeszélések a termékgazdával
    • sprint planning
    • sprint review
    • retrospective (visszatekintés)
• Kanban
  • kanban tábla (kanban board) vizualizálja a teendőket
  • vertikális elhejezés gyakran a fontosságot reprezentálja azonos kategóriában levő teendők között
  • fókuszban az elvárások
  • egyéni döntéshozatal
    • (mindenki magának rendezi a teendőit az elvárások halmazából a prioritás figyelembe vételével)
  • munkamennyiség és kiegészítő tevékenységek korlátozása
    • (kinek hány cetlije lehet)

SOLID tervezési elvek

• __S__ingle responsibility
• __O__pen Closed Principle
• __L__Iskov Substitution Principle
• __I__nterface Segregation Principle
• __D__ependency Inversion Principle

Single responsibility

• Egy felelősségi kör
• Ne legyenek "mindenható" objektumok
• Több objektum ne osztozzon egy felelősségi körön

Open Closed Principle

• Egy osztály legyen nyílt a kiterjesztésre, de zárt a módosításra
• A funkcionalitás bővítéséhez ne kelljen az osztályt módosítani
  • Kompozíciókkal és leszármazással megoldható

Liskov Substitution Principle

• A leszármazott osztály őrizze meg az ősosztály viselkedését
• Ha az ősosztály típus helyére a leszármazott osztályt tesszük, a funkcionalitás maradjon meg
  • Ezzel "teljesíti", amit a típustól elvárunk

Interface Segregation Principle

• Egyetlen kliens se függjön olyan eljárásoktól, amiket nem is használ
  • Az erre a célra készített interfészek jellemzően az 'able' végződést kapja (Comparable, Iterable)

Dependency Inversion Principle

• Magas szintű modul ne függjön alacsony szinttű moduloktól
• Mindkettő absztrakcióktól függjön
  • API-k

Architekturális minták

MV* jellemzően ugyanazt a problémát hivatott megoldani: a nézet és a modell különüljön el, amennyire csak lehet.

MVC

• Model-View-Controller
• A controller tárolja a modell és a nézet állapotát is
• A controller irányítja a nézetbeli elemeket (létrehozza, módosítja)
• A nézet a kontroller függvényeit hívja meg, majd a kontroller állítja át annak állapotát
• Jellemzően a nézet ismeri a modellt és a modell gyakran igazodik a bnézethez
• A nézethez egy kontroller tartozik, egy kontroller több nézetről is felelhet

MVA

• Model-View-Adapter
• Az adapter (másnéven mediating-controller) megköveteli, hogy a nézet és modell közötti kommunikáció kizárólaz rajta keresztül történjen
• A nézet nem ismeri a modelt, az adaptertől kér adatot
• A modell nem ismeri a nézetet, csak API-t ad
• Ugyanazon nézet és modell között több adapter kapcsolat is létrejöhet a különböző adatok és viselkedések kezelésére
  • Egy információ egy adapter
  • Egy viselkedés egy adapter

MVP

• Model-View-Presenter
• A presenter (másnéven supervising controller) a modell változását váltja ki (nem interaktál közvetlen a nézettel)
• A nézet a presenterről kap egy csak olvasható snapshot-ot a modell állapotáról
• A nézet a presentert eseményekkel, és a nála levő snapshot-tal hívja meg (jellemzően)
• A nézet a prezentertől kapott adattípust ismeri csak, és csak annak függvényeit/eseményeit éri el

MVVM

• Model-View-ViewModel
• A ViewModel tárolja a modell állapotát
• A nézet data-binding-al köt a ViewModel állapotához
• A ViewModel-el a nézet eseményekkel/függvényhívásokkal kommunikál
• A data-binding csak a szükséges adattal látja el a nézetet, a nézet csak a viewModel függvényeit/eseményeit éri el

Tervezési minták szerepe, osztályozása

Részenként 2 példa elég, de azért itt van minden :3

Létrehozási

Singleton

Biztosítja, hogy az osztálynak kizárólag egy, globális példánya létezhet egy időben (többszálú folyamatoknál is)

Gyakori felhasználás:

• Logger osztályok
• Config osztályok
• Megosztott erőforrások elérésére
• Más mintázat is Singleton-ként van implementálva
  • Factory, Abstract Factory
  • Builder
  • Prototype

Factory

Segíti a framework-beli interfészeket definiáló objektumok létrehozását anélkül, hogy implementációs részletektől függjön a hivó fél

Factory Method

A objektum kreátornak interfészt hagy, ami nem tudja, hogy milyen konkrék osztályt fog létrehozni az őt implementáló farctory (persze ők már tudják, mit fognak iniciálni). Az ősosztály lehet használni fogja a factoryMethod() által létrehozott elemet (a leszármazó osztályból).

Eredményül több factory lesz, mindegyik a főosztály általt definiált interfészt fogják tudni példányosítani.

Abstract Factory

Közös interfész a hasonló típusú elemek factory-ének.

Példában láthatóan két különböző interfészre egy közöt factory jön létre, aminek elemei közösen használhatóak (implementációt továbbra is elrejtve).

Builder

Lehetőséget ad arra, hogy az elem létrehozásához szükséges információkat a builder tárolja, amíg minden szükséges elem rendelkezésre nem áll.

A builder használata hasonló érzés lehet, mint egy fájl feletti folyamatos I/O sorozat

Példa: stringBuilder

Collection<T>.joinToString(): String{
  val boby = StringBuilder() 
  forEach { item -> 
      boby.append(item.toString()) 
  } 
  return boby.toString()
}

Ahol buildString a builder és azon belül az append() felvesz egy újjabb ideiglenes String szeletet, és csak a végén a toString meghívásakor lesz a String konstruktora meghívva.

Prototype

Egy prototípus létezik, minden további objektum ennek a prototípusnak valamilyen másolata lesz.

Object Pool

Olyan esetben, ha az objektumnak nincs "állapota" a kliensre nézve, azonban előállításuk költséges, vagy akár limitált, egy globálisan elérhető kollekcióból választhat a kliens (amíg van a kollekcióban).

Gyakori használat:

• Adatbázis kapcsolat
• Távoli objektumok

Szerkezeti

Adapter

Az osztály egyik interfészét egy másikká alakítja, hogy kommunikáció működjön.

Példa:

XmlToJsonAdapter

Bridge

Nagy, komplex objektumot több kicsi, egymáshoz közeli objektummá alakít, amik így egymástól függetlenül fejlődhetnek.

Hasonlóan, egy multiplatform keretrendszer az egymástól nagyban különböző implementációkat egy közös absztrakciós szintre emeli, így használata a kliens oldalon könnyen fenntartható.

Composite

Fa felépítést hoz létre (főnök/beosztott felosztás).

Komplex funkcionalitás alakítható ki részenként.

Decorator

Wrapper osztály, ami extra funkciót ad az eredeti osztálynak.

Több, hasonló funkció kombinációját tudja magában foglalni, így nem kell az eredeti oszutálynak minden variációra felkészülni.

Facade

Komplex folyamatokat és bonyolult implemnetációkat egy könnyen használható, egyszerűsített interfésszel helyettesít.

Használatuk hamar "mindent tudó" objektumokká válhat.

Amikor egy facade mérete kezd túl nagy lenni, érdemes megfontolni több, kissebb facade létrehozását és a felelősség delegálását.

Memento

A kezdeti állapotot menti el, míg az enkapszuláció nem sérül, majd (amennyiben szükséges) a kezdeti állapot visszaállítható.

Flyweight

Nagy méretű, nem módosuló elemeket érdemes kiszervezni, hogy ezzel is memóriát takarítsunk meg.

Különösen fontos nagyszámú ismétlődésnél, ahol az ismétlődő elem önmagában is nagy.

Proxy

A forrás eredeti függvényét megelőzheti a proxy valamilyen viselkedése, akár meg is kerülve azt.

A proxy lehet lusta iniciáló, ami az erőforrást csak használatkor foglalja le.

Adatbázis kapcsolat esetén a kapcsolat előtt is létrejöhet, mint hogy erről a kliens "tudjon".

Viselkedési

Chain of responsibility

Amikor több feltétel teljesítését külön objektumok látják el.

Minden objektum a felelősséglánc egyetlen eleméért felel, és azt tudja még, kit kell meghívjon következőnek, így vagy a korai hiba, vagy a végső siker bekövetkezik.

A felelősséglánc nem feltétlen csak lineáris adatszerkezetben tűnhet fel...

Command

Az elvégzendő utasítást objektumokkal reprezentálja, így több utasítás végrehajtása sorba állítható, vagy könnyen felfüggeszthető/visszavonható.

Egy command objektumnak annak végrehajtásához minden információt magában kell hordozzon.

Interpreter

Adj meg egy nyelvet, a hozzá tartozó nyelvtant és azt, hogy az interpreter a reprezentációval mit kezdjen.

Iterator

Lehetőséget ad arra, hogy a kollekció minden elemét bejárd úgy, hogy a reprezentáció számodra ismeretlen/irreleváns.

Bonyolultabb reprezentáción érdemesebb a bejárási stratégiákat egyszer definiálni, és nem minden alkalommal feltalálni a kereket.

Mediator

Köztes objektum, ami az osztályok közötti kommunikációt oldja meg úgy, hogy direkt referenciákra ne legyen szükség az osztályok között (mindenki csak a mediátorral kommunikál).

Observer

Értesítéseket kezel úgy, hogy minden feliratkozó értesítve legyen a változásról, ne keljel minden érdekeltnek kérdeznie, valamint olyan elemeket ne értesítsünk, amiket sosem érdekelt. (but rly, who tf asked??)

Strategy

Lehetőséget ad arra, hogy a kliens dinamikusan változtasson a végrehajtás módszerén/algoritmusán, míg használatuk a kliens oldalán megegyezik.

Template Method

Csontváza a végső viselkedésnek, a leszármazó osztályoknak a rész elemeket (függvények és propertyk) implementációja szükséges csak.

State

Megengedi az objektumnak, hogy a viselkedése a belső állapot függvényében megváltozzon.

Visitor

Meglévő osztály-szerkezet felett definiál további műveleteket anélkül, hogy az eredeti osztályokat megváltoztatná.

Null Object

Egyetlen jó módja a NO-OP implementáció, amikor tényleges leszármazó objektum nem elérhető.