Tervezési minta látható: Stratégiai minta

Ebben a blogban felfedjük a Strategy Design Pattern-t, amely dinamikusan választható algoritmusok cserélhető családjának létrehozására szolgál.

'



Üdvözöljük a „Design Patterns Exposed” sorozat első bejegyzésében. Ebben a sorozatban az egyes tervezési mintákat a semmiből tárjuk fel.



A programozási nyelv és annak konstrukcióinak puszta ismerete nem lesz jobb programozó vagy fejlesztő. A ma és a jövőben is működő szoftver létrehozásához a tervezési minták ismerete szükséges.

Sok fejlesztő már találkozott olyan tervezési problémákkal, amelyekkel most szembesül, vagy a jövőben szembesülni fog. Meghatározták a probléma kezelésének szokásos módját. A tervezési minták használatával tehát a bevált technikák előnyét élvezheti.



Minden tervezési minta egy adott helyzet megoldására szolgál, lehetnek olyan helyzetek, amikor egynél több tervezési minta használható.

A legtöbb programozó csak megpróbálja megoldani a problémát, anélkül, hogy a tervezési minták, a redundáns kód vagy a szoros összekapcsolás miatt aggódna. De a jó programozók másként kezdenek. Gondolkodnak a mai követelményeken, a jövőbeni követelményeken, a kód karbantartásán és a kód újrafelhasználhatóságán.

A jó programozók nem sietnek a kódolás megkezdésével, amint megkapják a követelményeket. Ülnek és gondolkodnak azon a problémán, hogy a tervezésük sikerül-e. Ha igen, akkor hat hónap múlva is működik-e, amikor a követelmények megváltoznak.



A jó programozók elveszik a tollukat és a papírjukat, és elkezdik megtervezni óráikat és az osztályok közötti kapcsolatot. Igyekeznek laza összekapcsolódást és nagy kohéziót elérni a tervezésük során, miközben mindezt objektum-orientált alapelvekkel gondolják. Nem mennek azonnal be az alacsony szintű kódba. Rugalmas és újrafelhasználható szoftverek tervezéséhez kövesse ezt a megközelítést, különben mindig azon kapja magát, hogy módosítja a korábban írt kódot.

Csak egy dolog van állandó a szoftveriparban, ez az Változás. A követelmények minden bizonnyal folyamatosan változnak. Tehát hogyan tervezzük meg azt a szoftvert, amelyet a kódod könnyen adaptálhat a jövőbeni követelményekhez? Ehhez korán kell kezdenie, és úgy kell megterveznie, hogy a jövőbeni követelmények ne törjék meg korábbi kódját.

Hogyan tehetném ezt?

Nos, ez megtehető az ezen elveken alapuló tervezési elvek és tervezési minták követésével.

Merüljünk el a kódolásban, és kezdjük el az utat, hogy jobb programozóvá váljunk. Ebben a bejegyzésben az egyik legfontosabb mintát tárjuk fel - Stratégiai minta .

Amikor azt mondom, hogy a legfontosabb, az a közös problémára reflektál, amelyet a Stratégiaminta megold.

Mi a stratégiai minta?

A definíció egyenesen a „Négyek bandája” könyvből származik:A stratégiai mintával felcserélhető algoritmuscsaládot hoznak létre, amelyből a kívánt folyamatot futás közben választják ki”.

Abban az esetben, ha vannem képes megérteni, ne aggódjon, elmagyarázzuk aegyszerűbbútnekedmegért.

Először értsük meg a problémát, majd meglátjuk, hogy a Stratégiaminta hogyan tudja ezt megoldani.

A fenti UML diagramon állati absztrakt osztály és két konkrét osztály, a Kutyák és a Madarak, amelyek az Animal super osztályból származnak.

Tehát határozzunk meg egy Animal absztrakt osztályt és két konkrét osztályt, a Dog and Bird-et.

Mit gondol a fenti kialakításról? Van egy nagy hiba a tervezésünkben.

Az összes állat nem tud repülni, mint a fenti esetben egy kutya sem. De mégis „légy” viselkedésű.

Hibát követtünk el, amikor az absztrakt fly () metódust az Animal osztályba írtuk. Ez a kialakítás minden alosztály kutyát, madarat, pingvint, krokodilt, libát stb. Rá fogja kényszeríteni a fly () módszer alkalmazására.

Meg kellett volna értenünk, hogy a repülés olyan képesség, amellyel nem minden állat rendelkezik. A fly () módszer biztosításával az Animal abstract osztályban minden alosztályban beállítottuk a repülési képességet, ami nem minden állat-alosztályra vonatkozik.

Gondolhatja, hogy mi a probléma a fly módszer alosztályokban történő megvalósításában. Bár a fly () metódust a nem repülő Animal alosztályokban is megvalósíthatja, hogy csak a „Nem tudok repülni” feliratot nyomtassa ki. De a probléma az, hogy a légy viselkedését továbbra is a nem repülő állatoknak adod. Ez nem helyes.

Milyen érzés hívni a dog.fly () vagy a crocodile.fly () nevet.

Tehát most megértettük, hogy a tervezésünk nem megfelelő, és el kell távolítanunk a fly () metódust az Animal alosztályból.

Mi lehet a másik módja annak, hogy osztályainkat úgy alakítsuk ki, hogy a tervezés ne kényszerítse az összes állat-alosztályt légy-viselkedésre.

Az egyik megoldás, amely azonnal eszembe jut, az, hogy létrehozhatunk egy repülési felületet légy módszerrel, és csak a repülni képes állatok fogják megvalósítani ezt a repülési felületet. Így nem kényszerítjük az összes állat-alosztályt a légy viselkedésének meghatározására. Így kódoljuk ezt a tervezési megközelítést.

Most az Animal osztályunk az alábbi kódnak fog kinézni, miután eltávolította a fly módszert az Animal osztályból.

Most definiáljuk a Flying felületet

Most a kutya osztály megváltozikmintaz alábbi kódot, és nem szükséges, hogy légy viselkedjen.

Lássuk néhány állat-alosztályunkat, amelyek repülési viselkedéssel rendelkeznek.

Megoldottuk korábbi problémánkat, de új bajba kerültünk, ez a „Kódmásolás”.

Mondjuk, 100 különböző repülő állat-osztályunk lesz. Le kell másolnunk a repülési viselkedés kódját, mivel a repülési felület nem képes megvalósítani a repülési viselkedést, és később, ha bármelyik alosztályban meg akarjuk változtatni a fly () metódus megvalósítását, akkor meg kell nyitnunk az osztályt és módosítanunk kell a kódot, ami rossz. Hiányzik valami nagy dolog, vagyis nem tudjuk megváltoztatni az osztály repülési viselkedését futás közben.

De ne aggódj, a Stratégiai Minta azért van, hogy kijusson ebből a problémából.

Tehát alakítsuk át kódunkat a Strategy Pattern használatához.

A repülő felület ugyanaz marad, mint amilyen. Ahelyett, hogy minden egyes repülő alosztály megvalósítaná magát a repülési felületet, külön konkrét osztályokat fogunk meghatározni, amelyek különböző repülési viselkedést valósítanak meg. Lássuk, hogyan kell ezt megtenni.

Tehát, hogy működik mindez, nézzük meg a TestClass-ot

A Strategy Pattern használatával most képesek vagyunk megváltoztatni bármely állat repülési viselkedését futás közben, vagyis anélkül, hogy bármilyen alosztályt kényszerítenénk magának a repülési viselkedésnek a meghatározására.

Mikor kell használni a Strategy Pattern-t?

Amikor dinamikusan meg akarja változtatni a futás közbeni viselkedést.

Vegyünk egy másik példát, hogy egyértelműen megértsük a stratégiai mintát.

A fenti Munkavállalói osztályban a munkavállaló fizetését a kijelölésétől függően állapítjuk meg. Ha egy alkalmazott „gyakornok”, akkor a tényleges fizetés kiszámításához 10% bónuszt adunk az alapfizetéshez.

Ha egy alkalmazott „webfejlesztő”, akkor a tényleges fizetés kiszámításához az alapilletményhez 20% -os bónuszt adunk, és hasonló folyamat következik más alkalmazottak esetében is. Bár a tényleges fizetés kiszámítására szolgáló algoritmusunk nagyon egyszerű, hogy könnyebben érthető legyen, de legtöbbször sok összehasonlítást és számítást tartalmaz.

Szóval, mi a baj a munkavállalói osztály kódjával?

Nos, a fizetés kiszámításának kódja (getPay ()) statikus. Tegyük fel, hogy az „Intern” bónuszát 10% -ról 14% -ra akarom változtatni. Meg kell nyitnom az Employee osztály kódját, és meg kell változtatnom.

És egy másik probléma, hogy nem tudom megváltoztatni a munkavállaló fizetési algoritmusát futás közben. Szóval, hogyan kell ezt megtenni? A Strategy Pattern kifejezetten az ilyen jellegű problémák kezelésére szolgál.

Tegyük át a kódot a Strategy Pattern használatához.

Több algoritmust fogok meghatározni a fizetés kiszámításához. Akkor ezeknek az algoritmusoknak a bármelyikét használhatom a futásidejű fizetés kiszámításához.

Most nézzük meg, hogyan fog változni az Alkalmazottak osztálya.

példa java távoli módszer meghívására

Jegyzet: Eltávolítottam a bérszámítás logikáját az Employee osztályból, és létrehoztam egy meghatározott PayAlgorithm () metódust, amelyen keresztül beállítom azt a PayAlgorithm-et, amelyet használni akarok a fizetés kiszámításához.

Ez rugalmasságot ad számomra a fizetés kiszámításához úgy, hogy bármilyen PayAlgorithm-et dinamikusan, futás közben adok meg. Azt is vegye figyelembe, hogy később, ha módosítanom kell a bérszámítási logikát, létrehozhatok egy új PayAlgorithm-et, és ezt használhatom a fizetés kiszámításához. Nem kell megváltoztatnom az előző kódot, nem jó?

Lássuk tehát működni.

Remélem, nagyon jól megértette a stratégiai mintát. A tanulás legjobb módja a gyakorlás.

Ha bármilyen kérdése van a stratégiai mintával vagy bármely más mintával kapcsolatban, hagyja alább a kérdéseit.

Vigyázz a következő bejegyzésre, ahol felfedjük az egyik legnépszerűbb tervezési mintát, a gyári mintát.

Addig letöltheti vele a kódjátékot, és biztos, hogy a fejében megkötötte a stratégiai mintát.

Van egy kérdésünk? Említse meg őket a megjegyzések részben, és mi kapcsolatba lépünk Önnel.

Kapcsolódó hozzászólások: