Tervezési minták

Ez a szegmens egy egyszerű megoldási folyamatot követ végig, felhasználva fontosabb tervezési mintákat, valamint az UML diagramokat.

A megoldást célszerű korábbi, hasonló feladatok megoldási mintái alapján felépíteni.

Erre vannak például az algoritmus minták (propramozási tételek) és tervezési minták (design patterns)

OOP modellezést támogató minták, leginkább az osztály diagram tervezése során használatos.

Az így készült kód újrafelhasználható, könnyen módosítható, biztonságosan működő és hatékony (plusz megfelel a SOLID elveknek).

Feladat - Testek

Objektum hierarhia - Testek

• Szabályos testek
  • Gömb
  • Kocka
  • Tetraéder
  • Oktaéder
• Hasáb jellegű testek
  • Henger
  • Hasábok
• Gúla jellegű testek
  • Kúp
  • Négyzetes gúla

Az alábbi példában könnyen alkalmazhatunk öröklődést, hogyha az ősosztályokat a közös tulajdonságok alapján határozzuk meg

Objektum hierarchia - leszármazásai

Absztrakt ősosztály - Test

• Minden test rendelkezik egy mérettel, amit majd publikussá tesz az adott objektum
• Minden testnek van térfogata, így annak getterének szignatúrája is benne van (implementációra vár)

Absztakt osztályok - Szabályos és Hasábszerű

• Szétválnak egyes közös tulajdonságok, azonban továbbra is absztrakt síkon járunk

Absztrakt ősosztály diagram

Kiegészítés, darabszám nyilvántartása

Osztályszinten nyilván tartható így a létrehozott testek száma

Szabályos testek

A "Szorzó" adattaggal a Térfogat felmehet a szabályos ősosztályba, ezzel elkerülve a felesleges kódismétlést (redundanciát)

Hasábféle testek

Kúpszerű testek

Interfész bevezetése

Az alapterület több objektumnál is előfordul, ami nem képezi részét a felállított hierarchiának. Itt az interface helye.

Stratégia (strategy tervezési minta)

A feladat interfészre definiálása megadja azt a szabadságot, hogy futási időben eldönthessük melyik, az interfészt megvalósító objekutot kívánjuk használni az adott szituációban.

Fontos példa a Java List interfésze, ami a lista szerű viselkedésért felel, azonban mind az ArrayList, mint a LinkedList implementációja más területeken jó, olykor a hasznosság csak futási időben derül ki.

Egyke (singleton) tervezési minta

Memóriapazarlás elkerülésére a singletonból csak egy elem lehetséges.

Az osztály nem absztrakt, viszont a konstruktora privát, mert kizárólag az objektum lekérésekor jöhet létre objektum, ha eddig nem volt.

Fontos megjegyezni, hogy az instance egy osztály szinttű adattag, ami az osztály típusával rendelkezik

Feladat - Lények túlélése

A feladatban egyes fajok túlélési képességét próbáljuk szimulálni

Egy lény egy lépése

Lény használati esetei

Terep állapotgépe

Állapot (state) tervezési minta

Egy objektum egyes állapotaihoz köthető viselkedését elkülöníthetjük úgy, hogy minden állapotot egy önálló objektum képviseljen.

Ezek az objektumok a rekakciókat (állapotváltozásokat) írják le

Így könnyen vezethető be új reakció, ezzel is kedvezve az Open-Closed elvnek

Lények osztályai

Látogató (visitor) tervezési minta

Amikor egy metódus az saját osztályán túl függ a paraméterül kapott osztály leszármazásától (hogy melyik alosztály lett paraméterül adva), de nem akarjuk, hogy ez a függőség megjelenjen a kódban.

Bár a megjelés azonos, szemantikailag az objektumok különböznek, ezért van szükség a többalakúságra.

Visitor tervezés hatása

A hatékonyság ellen megy a tény, hogy a terep változása minden esetben egy új példány létrejöttét eredményezi, ami elkerülhető Singleton viselkedéssel

Egy lény futama

Lények versenye

Minden lény elindul útjára, moment of virtuális kiválasztódás...