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.

public class Movie {

    public Money calculateMovieFee(Screening screening) {
        return fee.minus(discountPolicy.calculateDiscountAmount(screening));
    }

• 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

public abstract class DiscountPolicy {

    private List conditions;

    public DiscountPolicy(DiscountCondition... conditions) {
        this.conditions = Arrays.asList(conditions);
    }

    public Money calculateDiscountAmount(Screening screening) {
        for (DiscountCondition condition : conditions) {
            if (condition.isSatisfiedBy(screening)) {
                return getDiscountAmount(screening);
            }
        }
        return Money.ZERO;
    }

    abstract protected Money getDiscountAmount(Screening screening);
}

public class NoneDiscountPolicy extends DiscountPolicy {

    @Override
    protected Money getDiscountAmount(Screening screening) {
        return Money.ZERO;
    }

• 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.

public interface DiscountPolicy {

    Money calculdateDiscountAmount(Screening screening);
}

public abstract class DefaultDiscountPolicy implements DiscountPolicy {

    private List conditions;

    public DefaultDiscountPolicy(DiscountCondition... conditions) {
        this.conditions = Arrays.asList(conditions);
    }

    public Money calculateDiscountAmount(Screening screening) {
        for (DiscountCondition condition : conditions) {
            if (condition.isSatisfiedBy(screening)) {
                return getDiscountAmount(screening);
            }
        }
        return Money.ZERO;
    }

    abstract protected Money getDiscountAmount(Screening screening);
}

public class NoneDiscountPolicy implements DiscountPolicy {

    @Override
    public Money calculateDiscountAmount(Screening screening) {
        return Money.ZERO;
    }
}

public class PercentDiscountPolicy extends DefaultDiscountPolicy {

    private double percent;

    public PercentDiscountPolicy(double percent, DiscountCondition... conditions) {
        super(conditions);
        this.percent = percent;
    }

    @Override
    protected Money getDiscountAmount(Screening screening) {
        return screening.getMovieFee().times(percent);
    }
}

public class AmountDiscountPolicy extends DefaultDiscountPolicy {

    private Money discountAmount;

    public AmountDiscountPolicy(Money discountAmount, DiscountCondition... conditions) {
        super(conditions);
        this.discountAmount = discountAmount;
    }

    @Override
    protected Money getDiscountAmount(Screening screening) {
        return discountAmount;
    }

• 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