Bevezetés

Robert L. Glass azt állította, hogy a gyakorlat előbbre való, mint az elmélet. Különösen a szoftverfejlesztésben a gyakorlat vezető szerepet játszik az elmélethez képest, a fejlesztők a legtöbbet akkor tanulják meg, amikor konkrét kóddal dolgoznak. Ezért az elméletet és a fogalmakat félretéve, szeretnénk megvizsgálni egy egyszerű programot.

Jegyértékesítő alkalmazás implementálása

• Kis rendezvényt szeretnénk szervezni egy kis színház népszerűsítése céljából.
  • Esemény tartalma: sorsolás útján kiválasztott nézőknek ingyenes jegyet küldünk a produkcióra
• Szelektálnunk kell az esemény nyerteseit és a veszteseket.
  • Esemény nyertesei: jegyek cseréje meghívóra
  • Esemény vesztesei: jegyek megvásárlása pénzért

Gyakorlati kód: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Mi a probléma?

Robert Martin három funkciót ír le, amelyet egy szoftver modulnak (mérettől függetlenül, akár osztály, csomag, vagy könyvtár, bármi, ami egy programot alkot) teljesítenie kell.

• Hibátlanul működik futás közben.
• Módosításra szánják.
  • Egyszerű műveletekkel módosíthatónak kell lennie.
• Közli az információt a kódot olvasókkal.
  • Könnyen olvashatónak és érthetőnek kell lennie a fejlesztők számára.

A korábban említett jegyértékesítő alkalmazás megfelel az első feltételnek, a hibátlan futásnak, de a módosíthatóság és a kommunikáció szempontjából nem teljesít jól.

Váratlan kód

Nézzük meg, miért nem teljesíti a kommunikációs célt.

• A Theater osztály enter() metódusa mit csinál?
  • A színház kinyitja a néző táskáját, és megnézi, van-e benne meghívó.
  • Ha a táska tartalmaz meghívót, utasítja az eladót, hogy vegye ki a pénztárnál tárolt jegyet, és tegye a néző táskájába.
  • Ha nincs meghívó a táskában, a néző táskájából kiveszi a jegy árának megfelelő összeget, megvásárolja a jegyet, és a jegyet a táskába teszi.
• A néző szempontjából a színház, mint harmadik fél, önkényesen kutat a táskájában, elveszi a pénzét és berakja a jegyet.
• Az eladó szempontjából a színház, mint harmadik fél, engedély nélkül manipulálja a pénztárnál lévő jegyek és pénz értékét.
• Az érthető kód azt jelenti, hogy a működés nem tér el jelentősen az elvárásainktól, a fenti színház azonban eltér a várakozásainktól.
  • A nézőnek saját maga kell kivennie a pénzét a táskájából, és fizetnie kell az eladónak a jegyért.
  • Az eladónak saját maga kell kivennie a pénztárnál lévő jegyet, átadnia a nézőnek, és a nézőtől kapott pénzt visszatenni a pénztárba.
• Ezenkívül az enter() metódus megértéséhez számos részletet kell megjegyezni.
  • Az Audience objektumnak Bag objektumja van.
  • A Bag objektum tartalmaz pénzt és jegyet.
  • A TiketSellet objektum jegyeket árul a TicketOffice-ból, a TicketOffice objektum tartalmaz pénzt és jegyet.

Módosításra hajlamos kód

Az enter() metódus két feltételezést tesz.

• A néző mindig táskát hord magával, hogy pénzt és meghívót tartson benne.
• Az eladó csak a pénztárnál árul jegyeket.

Mi lenne, ha a következők történnének?

• A nézőnek nincs táskája.
• A néző nem pénzzel, hanem hitelkártyával fizet.
• Az eladó a pénztárnál kívül is árulhat jegyeket.

Például az első követelmény teljesítéséhez el kell távolítani az Audience osztály Bag objektumát, és módosítani kell a Theater osztály enter() metódusát. Ez azért van, mert a Theater osztály túlságosan részletes információkra támaszkodik arra vonatkozóan, hogy a nézőnek van táskája, és az eladó csak a pénztárnál árul jegyeket. Ha ezek közül bármelyik részlet megváltozik, módosítani kell mind az adott osztályt, mind a függő osztályokat (pl. Theater).

Ez az objektumok közötti függőséggel kapcsolatos probléma, a függőség pedig változásokra gyakorolt ​​hatást jelez. Az objektumorientált tervezés azonban célja együttműködő objektumok közösségének létrehozása, amelyek kölcsönösen függenek egymástól, ezért nem szabad a függőséget önkényesen eltávolítani, hanem csak az alkalmazás funkcióinak megvalósításához szükségesminimális függőség fenntartásaés a felesleges függőségek eltávolítása.

Ha a függőség túlzott mértékű az objektumok között, akkor aztmagas összekapcsoltságnak nevezik, és minél magasabb az összekapcsoltság két objektum között, annál nagyobb a valószínűsége annak, hogy együtt kell módosítani őket. Ezért a tervezés célja a lehető legalacsonyabb összekapcsoltság elérése az objektumok között, hogy a módosítások könnyebben végrehajthatók legyenek.

A tervezés javítása

A Theater-nek nem kell tudnia, hogy a nézőnek van táskája, és az eladó a pénztárnál árul jegyeket. A Theater csak azt akarja, hogy a néző belépjen a színházba. Ezért a nézőt autonóm entitássá kell tennünk, aki saját maga kezeli a táskájában lévő pénzt és meghívót, és az eladót autonóm entitássá, aki saját maga kezeli a pénztárnál lévő jegyeket és az értékesítési díjakat.

Növeljük az autonómiát

Azokat az objektumokat, amelyek szorosan összefüggő feladatokat végeznek, és a nem összefüggő feladatokat más objektumoknak delegálják, magas kohézióval rendelkező objektumoknak nevezzük. Az autonóm objektumok létrehozása, amelyek saját adatokat kezelnek, segít az összekapcsoltság csökkentésében és a kohézió növelésében.

Eljárási és objektumorientált

• Eljárási
  • A Theater enter() metódusa eljárás, az Audience, TicketSeller, Bag, TicketOffice adatok.
  • Az eljárásokat és az adatokat külön modulokban elhelyező megközelítést eljárási programozásnak nevezik.
  • Sokan nem felelnek meg a természetes logikának (pl. a néző maga kezeli a pénzét és a meghívót).
  • Nehéz leszűkíteni az adatok módosításának hatását.
  • A felelősség központosított (a Theater kezeli mindent).
• Objektumorientált
  • Az adatok és az eljárások ugyanabban a modulban helyezkednek el, ezt objektumorientált programozásnak nevezik.
  • Természetes logikának megfelelő kódot írhatunk.
  • A kapszulázás révén hatékonyan leszűkíthetjük az adatok módosításának hatását.
  • Minden objektum felelős önmagáért.
  • 
    

Gyakorlati kód: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Továbbfejleszthető.

• Az Audience osztály Bag osztálya továbbra is passzív lény, amelyet az Audience osztály irányít, ezért a Bag osztályt autonóm objektummá kell alakítani.
• A TicketSeller osztály TicketOffice osztálya szintén a TicketSeller által irányított, és tetszőlegesen kezelhető. A TicketOffice-ot autonóm objektummá kell alakítani.
  • Azonban a módosítás után a TicketOffice további összekapcsoltságot hozott létre az Audience-szal.
  • A tervezés során a kompromisszumokat kell figyelembe venni. Ebben az esetben a TicketOffice-ot viszonylag passzív objektummá tehetjük, hogy csökkentsük az összekapcsoltságot az Audience-szal.

Gyakorlati kód: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Igen, hazugság!

• Bár a valóságban passzív lények, az objektumorientált világba belépve minden aktív és autonóm entitássá válik.
• Jó, ha a személyeskedés segítségével a passzív objektumokat olyan lényekként képzeljük el, amelyek nevetnek, beszélnek és haragszanak.

Objektumorientált tervezés

Miért van szükség tervezésre?

• A tervezés a kód elhelyezése.
• A jó tervezés olyan, amely teljesíti a mai követelményeket, és lehetővé teszi a jövőbeni módosítások zökkenőmentes végrehajtását.

Objektumorientált tervezés

• A módosítható kód könnyen érthető kód.
• Az objektumorientált paradigma lehetővé teszi, hogy ugyanúgy írjunk kódot, mint ahogyan látjuk a világot.
• Az objektumok autonóm lények, amelyek felelősek a saját adataikért.
• A kiváló objektumorientált tervezés olyan tervezés, amely megfelelően kezeli a együttműködő objektumok közötti függőségeket.

Forrás

• Objektumok