A refaktorálás célja a kód átdolgozása, ésszerűsítése.
Korábban már megtanultam, hogy az elágaztatás vagy a switch használata utal(hat) egy vagy több SOLID elv megsértésére.
A példák amit találtam switch kiváltására szolgálnak. Lényegében adott objektumon kell az adott feltétel szerint eltérő beavatkozást tenni.
Kérdéses, hogy ez sérti e az egyetlen felelősség elvét, hiszen a feladat logikailag azonos.
Viszont a nyit/zárt elv (Egy osztály vagy modul legyen nyílt a kiterjesztésre, de zárt a módosításra.) alkalmazható az esetre. Hiszen bármelyik ág változtatási igénye esetén ennek az osztálynak a forrásában kell változtatni. Az adott objektumból származtatva létre lehet hozni az adott feladatot speciálisan kezelni tudó objektum osztályokat. Amelyek ebből eredően, csak rájuk vonatkozóan végzik el a tennivalókat. Itt mindjárt érvényesül a Liskov helyettesítési elv (Minden osztály legyen helyettesíthető a leszármazott osztályával anélkül, hogy a program helyes működése megváltozna.).
Az ismertető részben már utaltam arra, hogy ez az eljárás, objektum leszármaztatással operál. A SOLID elvekből eredően, az adott objektumra vonatkozó tevékenység az adott objektumban megfelelő helyen van.
(Zárójelben megjegyzem, szóba jöhet a stratégia tervezési minta használata is. Ekkor a stratégiákat megvalósító osztályok közös interfészt valósítanak meg. Így logikailag rokon az a megoldás. Illetve szolgáltató osztály is alkalmazható, ha a modell osztály tisztán tartása is cél. Ez utóbbi esetben ez az eljárás alkalmazható a szolgáltató osztály leszármaztatásával.)
A cél az, hogy minden az elágaztatási ághoz létezzen egy származtatott osztály amely speciálisan tudja elvégezni a feladatot.
A SOLID elvek érvényesítése mellett az elágazó szerkezet kitölti a metódus testét. Amennyiben az elágazó szerkezet mégis része egy eljárásnak, ki kell azt emelni metódusként.
Minden elágaztatott esethez létrejön egy a bázis osztálból származtatott osztály, amely felülbírálja az elágazást tartalmazó eljárást. A default ágban található kód marad az objektum eredeti osztályába. Elképzelhető, hogy valamelyik ágon nincs teendő, akkor abban az osztályban “üresen” kell implementálni a metódust.
Az eljárás lényegéről itt olvashattok.
