'
Ü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: