Ez lehetővé teszi a viselkedés és a viselkedést alkalmazó osztály jobb szétválasztását. A viselkedést anélkül tudjuk megváltoztatni, hogy betörnénk az osztályt, ami használja, illetve az osztályok lecserélhetik viselkedésüket a konkrét megvalósítás megváltoztatása által, anélkül hogy a kódot jelentőségteljesen megváltoztatnánk. A viselkedés változhat futási időben és tervezési időben is. Például az autó objektum fék viselkedését megváltoztathatjuk BrakeWithABS() -ről Brake() -re azáltal, hogy megváltoztatjuk a brakeBehavior tagot az alábbi módon: brakeBehavior = new Brake (); /* Algoritmusok egységbezárt családja * Interfész és annak megvalósításai */ public interface IBrakeBehavior { public void brake ();} public class BrakeWithABS implements IBrakeBehavior { public void brake () { System. println ( "Brake with ABS applied");}} public class Brake implements IBrakeBehavior { System. Stratégiai terv minta di. println ( "Simple Brake applied");}} /* Kliens mely a fenti algoritmusokat váltakozva használhatja */ public abstract class Car { protected IBrakeBehavior brakeBehavior; public void applyBrake () { brakeBehavior.
Az a tény azonban, hogy hamar túl akarunk lenni rajta, nem segít abban, hogy valóban gyorsabbak legyünk. Legfeljebb olyan határidők vállalására sarkall, amik eleve tarthatatlanok, így viszont minden borul, amit szeretnénk a jövő évben megvalósítani. Emellett előfordulhat, hogy a megoldásra szoruló problémát csak felületesen kezeljük az idő szűke miatt. Kulcsfontosságú tehát, hogy vállalható határidőket adjunk meg. Valószínűleg már tudjuk tapasztalatból, hogy egy-egy folyamatnak mennyi az átfutása, mikor válnak valamelyest kézzelfoghatóvá az eredmények. Nos, ehhez még adjunk hozzá egy kicsit, hogy ha bármilyen oknál fogva (sürgős projekt stb. ) csúszunk, ne tolódjon minden. A jó időbeosztás titka nem a szorosság, épp ellenkezőleg: a rugalmasság. Ez a kulcsa annak, hogy ne boruljon minden, ha valamilyen azonnal megoldandó eset adódik. Államháztartási Belső Kontrollok. A szerepkörök tisztázása Lényeges kérdés a célok sikeres megvalósításával kapcsolatosan, hogy mekkora mozgásteret kap a HR. Ezt a vezetőséggel egyeztetve, előre lehet tisztázni, és fontos, hogy mindenki tartsa is magát a megbeszéltekhez.
A stratégia minta szerint az osztály viselkedését nem szabad örökítenünk. Ehelyett egységbe kell zárnunk interfészek alkalmazásával. Például vegyünk egy Autó osztályt. Az Autó két lehetséges funkciója a fék és a gyorsulás. Stratégiai terv minta karya. Mivel a gyorsulás és a fék viselkedése gyakran eltérő a különböző modellek esetén, az általános felfogás szerint ezeket a viselkedéseket külön osztályokba sorolnánk, amelyek ugyanazt az interfészt valósítják meg, a kód öröklésének kiiktatásával. Ennek a megközelítésnek viszont jelentős hátrányai vannak: minden egyes új autómodellhez újra kell értelmezni a gáz és a fék viselkedését. Ezen viselkedések kezelésével járó munka a modellek számának a növekedésével jelentősen megnő, és kód-duplikációhoz vezethet. Továbbá nem egyszerű feladat meghatározni minden modell pontos viselkedését anélkül, hogy a bennük megírt kódot külön megvizsgálnunk. A stratégia minta öröklés helyett kompozíciót használ. Itt a viselkedést különálló interfészként és specifikus osztályokként definiáljuk, melyek ezeket az interfészeket valósítják meg.
A számítógép-programozásban a stratégia minta (vezérelv mintaként is ismert) egy szoftvertervezési minta, amely lehetővé teszi, hogy egy algoritmus viselkedését a futás során válasszuk meg. A stratégia minta meghatározza az algoritmusok egy családját, egységbe foglal minden algoritmust, és a családon belül cserélhetővé teszi ezeket az algoritmusokat. HR stratégia: hogyan készíts tartható tervet | Profession.hu. A stratégia segítségével az algoritmus az őt használó kliensektől függetlenül változhat, miután az megtette a beállításokat. A stratégia minta az egyike a Design Patterns könyvben [1] szereplő mintáknak, mely népszerűsítette a minták használatát a szoftvertervezés folyamatában. Például egy osztály, mely bejövő adatokat érvényesít, stratégiai mintát használhat a validációs algoritmus kiválasztására a bejövő adat típusa, az adat forrása, felhasználói választás vagy más megkülönböztető tényező alapján. Ezek a tényezők nem minden esetben ismertek a futtatás előtt, és szükségessé válhat radikálisan eltérő érvényesítési módok használata. A validációs stratégiákat, melyeket külön egységbe zártunk a validáló objektumoktól, a rendszer más területéről származó validációs objektumok (vagy akár más rendszerek) is használhatják kódduplikáció nélkül.