SZILÁRD alapelvek: Egyedülálló felelősség

SZILÁRD alapelvek: Egyedülálló felelősség

Ha Ön egy szenvedélyes fejlesztő, aki szeretne megtanulni kiváló minőségű szoftvermegoldásokat írni, akkor jó helyre jött barátom.

Az egyik legelterjedtebb és leghatékonyabb szoftverfejlesztési elv a SOLID elv, amelyet Robert C. Martin, Bob bácsiként ismert. Céljuk, hogy a szoftverterveket érthetőbbé, rugalmasabbá és karbantarthatóbbá tegyék.

A SOLID 5 tervezési elv mozaikszója:

1. Segyetlen felelősség.
2. Otollal zárva.
3. Liskov csere.
4. Iinterfész szegregáció.
5. Dfüggőség inverziója.

Ebben a cikkben az első és legegyszerűbbről fogunk beszélni, amely az Egyedülálló felelősségelv.

Az egységes felelősség elve azt mondja

„Egy osztálynak csak egy oka lehet a változásra”

De mit jelent a „csak egy ok” kifejezés!

Tudod, szerintem a példák a legjobb tanárok. Olvassuk el a következő kódrészletet, hogy megértsük.

class MusicPlayer{
   void playMusic(){
      System.out.println("Let the fun begins!");
   }
   void openPhoto(){
      System.out.println("Really! should I open the photo now?");
   }
}

Mint láthatja, van egy zenelejátszó osztályunk, amely képes zenét lejátszani és fényképeket nyitni.

Próbáld meg elképzelni, hogy ez az osztály létezik valamelyik projektben az XYZ cégnél, akinek dolgozik. Khaled az XYZ fotósa, és az Open Photo funkciót használja a fényképek megnyitásához. Ali egy másik alkalmazott, aki zenefüggő, és a zenelejátszás funkciót használja.

Ha Khaled úgy dönt, hogy megváltoztatja a fotók megnyitásának módját, akkor nyissa meg a MusicPlayer osztályt, és módosítsa az openPhoto funkciót. Hasonlóképpen, ha Ali, egy teljesen más alkalmazott, és talán egy másik osztályról döntött így. Ugyanezt fogja tenni, csak a playMusic funkcióval.

Két különböző indokot adtunk az osztálynak a változtatásra, és ezek nem kapcsolódnak egymáshoz. Az egyik a zenéhez, a másik a fényképekhez. Emellett mi a kapcsolat a MusicPlayer osztály és az openPhoto funkció között? Tudom, hogy arra gondoltál, hogy az openPhoto-nak nem kellene ott lennie.

Az osztály úgy néz ki, mint egy diák, aki két teljesen különböző munkahelyen dolgozik. A szoftverfejlesztésben ez rossz gyakorlat. Minél több dolgot tud egy osztály megtenni, annál érzékenyebb a változásra, így több a hiba és a probléma.

Nem csak ez, próbálja meg elképzelni, ha úgy döntöttünk, hogy eltávolítunk néhány kódsort a playMusicból, hogy megállapítsuk, hogy az openPhoto összeomlik. Egy helyen különböző dolgok hatással lehetnek egymásra. Mindenhol bogarak barátom, bogarak mindenhol!

Tehát válasszuk szét a felelősségeket, és adjunk egy okot egy osztálynak a változtatásra.

class MusicPlayer{
   void playMusic(){
      System.out.println("Let the fun begins!");
   }
}
class PhotoViewer{
   void openPhoto(){
      System.out.println("What about now should I open it?");
   }
}

Ha úgy döntünk, hogy bármikor megváltoztatjuk a fénykép funkciót, akkor nem érintjük a zenei funkciókat, és fordítva. Emellett a függvények logikailag is összefüggenek az osztályaik nevével.

A gyakorlatban nagyon nehéz egyetlen okot megadni az osztálynak a változtatásra, mivel számos függvény létezik, de amit tehetünk, az az, hogy a funkciókat amennyire csak tudod, kapcsold össze. Ezt a szoftverfejlesztésben általában kohéziónak nevezik. A nagy kohéziós osztályok a jó tervezés jelei.

A funkciókra is alkalmazhat egyetlen felelősségi elvet. Egy függvénynek egy meghatározott feladatot kell elvégeznie, nem többet vagy kevesebbet.

Mindig kérdezd meg magadtól, amikor egy függvényt írsz, mit csinál az? ha azt mondja, hogy csinál valamit „és”. És itt azt jelenti, hogy rosszul csinálod.

Egyelőre itt a vége az utunknak.

Hamarosan újabb utazásra indulunk a nyitott-zárt elvvel. Csak várj rá!