[Objektumok] 2. fejezet: Objektumorientált programozás

Filmjegy-foglalási rendszer

Követelmények áttekintése

Online filmjegy-foglalási rendszer létrehozása a cél.
A film a film alapvető adatait mutatja be.
- Cím, lejátszási idő, ár információk stb.
A vetítés a film tényleges nézői által való megtekintését mutatja be.
- Vetítési dátum, idő, sorszám stb.
Az emberek filmre foglalnak jegyet, de valójában egy adottvetítésrefoglalnak jegyet.
Kedvezmény feltételek
- Az ár kedvezményének lehetősége
- Sorszám feltétel: a vetítés sorszámát használja a kedvezmény meghatározásához
- Időszak feltétel: a film lejátszási kezdetének időpontját használja a kedvezmény meghatározásához
Kedvezmény politika
- Kedvezményes díj meghatározása
- Összegkedvezmény politika: a foglalási díjból egy meghatározott összeget von le
- Százalékos kedvezmény politika: az eredeti ár egy meghatározott százalékát vonja le
Filmre lehet egyetlen kedvezmény politikát rendelni, vagy egyáltalán nem, a kedvezmény feltételeket viszont több lehetőség kombinálásával is meghatározhatjuk.
Ha van kedvezmény politika, de nem teljesülnek a feltételek, vagy nincs kedvezmény politika, akkor a díj nem kerül kedvezményezésre.

Objektum-orientált programozás felé

Együttműködés, objektumok, osztályok

Az objektum-orientált programozás az objektumokra irányul.
- Ne az osztály meghatározása után gondolkozzunk azon, hogy milyen attribútumokra és metódusokra van szükségünk az osztályban.
- Meg kell határoznunk, hogy mely objektumok milyen állapotokkal és viselkedéssel rendelkeznek.
- Az objektumokat nem önálló entitásoknak, hanem együttműködő közösség tagjainak kell tekintenünk.

A domain szerkezetét követő programstruktúra

A domain a probléma megoldásához szükséges terület, amelyhez a felhasználó a programot használja.

Általában az osztály neve megegyezik a megfelelő domain fogalom nevével, vagy legalábbis hasonlónak kell lennie.
Az osztályok közötti kapcsolatot is a lehető legjobban a domain fogalmak közötti kapcsolathoz kell igazítani, hogy a program struktúrája könnyen érthető és előre látható legyen.

Osztályok megvalósítása

Az osztályok belső és külső részből állnak, és egy kiváló osztály megtervezéséhez meg kell határoznunk, hogy mely részt tesszük nyilvánossá, és melyet rejtünk el.
- Az objektum attribútumait private-ként blokkoljuk, és a belső állapot módosításához szükséges metódusokat public-ként nyitva tartjuk.
Az osztály belső és külső részének elkülönítése biztosítja az objektum önállóságát, így a programozónak szabadsága van a megvalósításban.

Önálló objektumok

Az objektumoknak önálló objektumoknak kell lenniük, állapotokkal és viselkedéssel.
A adatok és a funkciók együttesen történő összekapcsolását a objektumon belül kapszulázásnak nevezzük.
A hozzáférési szabályozás segítségével csökkenthető a külső beavatkozás, így az objektum képes önállóan dönteni a viselkedéséről.
Az interfész és a megvalósítás szétválasztásának elve a objektum-orientált programozás egyik fő elve.
- Nyilvános interfész: külsőleg elérhető rész
- Megvalósítás: belsőleg elérhető rész

A programozó szabadsága

A programozók szerepe osztály-íróra és kliens-programozóra oszlik.
- Az osztály-író új adattípusokat hoz létre.
- A kliens-programozó használja az osztály-író által létrehozott adattípusokat.
Megvalósítás elrejtése
- Az osztály-író csak a szükséges részeket teszi elérhetővé a kliens-programozó számára, így elrejtheti a belső megvalósítást.
- A kliens-programozónak csak az interfészt kell ismernie, így csökkenthető a tudás mennyisége.

Együttműködő objektumok közössége

A pénz kifejezésekor nem célszerű egyszerűen egy Long típusú változót deklarálni, hanem egy Money objektummal kell beburkolni. Az objektumok használata javítja az értelmezést, és lehetővé teszi a redundáns műveletek végrehajtását egy helyen.
A rendszer bizonyos funkcióinak megvalósításához szükséges objektumok közötti kölcsönhatást együttműködésnek nevezzük.

Rövid történet az együttműködésről

Az objektumoknak csak üzenetek küldésével vagy fogadásával lehet kölcsönhatásba lépniük egymással.
A fogadott üzenet feldolgozásához szükséges saját módszert metódusnak nevezzük.
Fontos megkülönböztetni az üzeneteket és a metódusokat, innen indul ki a polimorfizmus fogalma.

Kedvezményes díj lekérdezése

Kedvezményes díj kiszámításához szükséges együttműködés megkezdése

A Movie osztály nem tartalmaz részletes logikát a kedvezmény politikáról, hanem átadta azt a DiscountPolicy interfésznek. Az öröklődés, a polimorfizmus és az absztrakció használata elengedhetetlen.

Kedvezmény politika és kedvezmény feltételek

Öröklődés és polimorfizmus

Fordítási időbeli függőség és futási időbeli függőség

A kód függősége és a futási időbeli függőség eltérhet.
Minél nagyobb a különbség a kettő között, annál nehezebb megérteni a kódot, de annál rugalmasabb és bővíthető lesz.

A különbségen alapuló programozás

Az öröklődés lehetővé teszi új osztályok gyors és egyszerű hozzáadását egy meglévő osztály alapján, és lehetővé teszi a szülő osztály megvalósításának újrafelhasználását.
A szülőosztályhoz képest eltérő részek hozzáadásával új osztályok létrehozásának módját a különbségen alapuló programozásnak nevezzük.

Öröklődés és interfész

Az öröklődés révén a szülő osztály által biztosított összes interfészt a gyermek osztály örökli.
Az interfész definiálja az objektum által értelmezett üzenetek listáját.

```javascript public class Movie {

}

A Movie a calculateDiscountAmount üzenetet küldi a DiscountPolicy-nak. A Movie szempontjából nem számít, hogy melyik osztály példánya válaszol, csak az, hogy a válasz sikeres legyen.
Ezért az AmountDiscountPolicy és a PercentDiscountPolicy egyaránt helyettesítheti a DiscountPolicy-t a Movie-val való együttműködésben.
Az ilyen gyermekosztályok szülőosztály helyett történő használatát felkonvertálásnak nevezzük. Ez azért van, mert a gyermekosztály automatikusan konvertálódik a felsőbb szintű szülőosztályba.

Polimorfizmus

A polimorfizmus azt jelenti, hogy az objektumok képesek eltérően válaszolni ugyanarra az üzenetre az objektum típustól függően.
- A Movie ugyanazt az üzenetet küldi, de az, hogy melyik metódus kerül ténylegesen végrehajtásra, az üzenet fogadó objektumának osztályától függ.
A polimorfizmus a program fordítási időbeli függőségének és futási időbeli függőségének eltérésén alapul.
A polimorfizmus a metódus futási időbeli kiválasztását eredményezi, ezért késői kötésnek vagy dinamikus kötésnek nevezzük.

Interfész és polimorfizmus

Ha a megvalósítást nem kell megosztani, és csak az interfészt szeretnénk megosztani, akkor az absztrakt osztály helyett interfészt kell használni.

Absztrakció és rugalmasság

Az absztrakció ereje

Az absztrakció előnyei
- Az absztrakciós hierarchia külön tekinthető, lehetővé teszi a követelmények politikájának magas szintű leírását.
- Rugalmasabb lesz a tervezés.

Rugalmas tervezés

Az absztrakció megakadályozza a tervezés konkrét helyzetekhez való kötődését, így rugalmasabb tervezést tesz lehetővé.

Absztrakt osztály és interfész kompromisszum

```javascript public abstract class DiscountPolicy {

}

public class NoneDiscountPolicy extends DiscountPolicy {

}

Jelenleg a NoneDiscountPolicy valójában nem szükséges, mivel a DiscountPolicy calculateDiscountAmount() metódusában 0-t ad vissza, ha nincs kedvezmény feltétel. De a felhasználó számára könnyebben érthetővé teszi a Movie argumentumait, ha van egy None politika, amely nem tartalmaz kedvezményt.
Ezért a koncepció szempontjából a NoneDiscountPolicy osztály zavaró lehet, és az alábbi módosítással könnyebben érthetővé válik.

```javascript public interface DiscountPolicy {

}

public abstract class DefaultDiscountPolicy implements DiscountPolicy {

}

public class NoneDiscountPolicy implements DiscountPolicy {

}

public class PercentDiscountPolicy extends DefaultDiscountPolicy {

}

public class AmountDiscountPolicy extends DefaultDiscountPolicy {

}

A DiscountPolicy interfész absztrakcióval lett ellátva, és megkülönböztetik a NoneDiscountPolicy és az általános kedvezmény politikát jelölő DefaultDiscountPolicy implementációját.

A NoneDiscountPolicy számára külön interfész hozzáadása lehet, hogy a megnövekedett összetettséghez képest kevésbé hatékonynak tűnik.
Tudnunk kell, hogy minden írt kód kompromisszum eredménye. Vagyis minden írt kódnak meg kell felelnie egy meghatározott célnak.

Kód újrafelhasználása

Az öröklődés használható a kód újrafelhasználásához.
De a kód újrafelhasználásához az öröklődés helyett inkább a kompozíciót kell használni.
A jelenlegi kódban a Movie osztály a DiscountPolicy kódját a kompozíció segítségével használja újrafel.
Ha a Movie-t szülőosztálynak tekintjük, és AmountDiscountMovie és PercentDiscountMovie osztályokat hozzunk létre, akkor az öröklődést használtunk volna.

Öröklődés

Az öröklődés hátrányai
- Sérti a kapszulázást.
  - Ismernünk kell a szülőosztály belső struktúráját.
  - A szülőosztály módosítása esetén nagy a valószínűsége annak, hogy a gyermekosztályt is módosítani kell.
- Rugalmatlanná teszi a tervezést.
  - A szülőosztály és a gyermekosztály közötti kapcsolatot a fordítási időben határozzák meg.
  - A futási időben nem lehetséges az objektum típusa megváltoztatása.
  - De a kompozíció révén a changeDiscountPolicy() metódus segítségével a használó osztály megváltoztathatja az példányt futási időben.

Kompozíció

A kód újrafelhasználásának módját, amelyben csak az interfészben definiált üzeneteket használjuk, kompozíciónak nevezzük.
Lehetővé teszi a kapszulázást, és laza kapcsolódást tart fenn.
A polimorfizmushoz az interfészek újrafelhasználása esetén az öröklődést és a kompozíciót kombinálni kell.
- Például a DiscountPolicy interfészhez elkerülhetetlen az öröklődés használata az alsóbb szintű implementációk létrehozásához.

Forrás

Objektumok