Bárki, aki rendelkezik valamilyen tapasztalattal a szoftver programozásában, megítéli a mások által írt szoftver kódot, karrierjük alapján megítélési paramétereket használva.
Szakmai pályafutásom során sok fejlesztőt ismertem, és több ezer sornyi kódot láttam, és amikor értékelnem kell egy fejlesztő képességeit, akkor főleg két tényezőt vizsgálok:
Szerencsére vannak olyan alapismeretek vagy elvek, amelyek megkönnyítik a kódolás jobb fejlesztését.
a SOLID rövidítés a következőket jelenti:
S: az egyetlen felelősség elve
O: nyitott-zárt elv
L: Liskov helyettesítési elv
I: Az interfész elkülönítésének elve
D: A függőségek inverziójának elve
Kezdjük azzal, hogy elmélyüljünk az első SZILÁDD elvben, nevezetesen a
Egy osztálynak (vagy modulnak) csak egy oka lehet a változásra, a fejlődésre.
Maga a koncepció nagyon egyszerű, de ennek az egyszerűségnek az elérése érdekében a megvalósítási út nagyon bonyolult lehet. Egy osztálynak csak egy oka lehet a váltásra.
De miért?
Miért olyan fontos, hogy csak egy oka van a változásra?
Például, ha két különböző oka van a változtatásnak, elképzelhető, hogy két különböző csapat ugyanazon a kódon dolgozhat két különböző okból. Mindegyiknek meg kell valósítania a saját megoldását, amely egy lefordított nyelv (például C ++, C # vagy Java) esetén olyan modulokhoz vezethet, amelyek nem kompatibilisek más csapatokkal vagy az alkalmazás más részeivel.
Egy másik példa, ha értelmezett nyelvet használ, előfordulhat, hogy ugyanazon osztályt vagy modult különböző okokból újra kell tesztelnie. Ez több munkát, időt és erőfeszítést jelent a minőség-ellenőrzés érdekében.
Az osztály vagy modul egyetlen jellemzőjének azonosítása sokkal összetettebb, mint egyszerűen egy ellenőrzőlista megtekintése a tesztek futtatásához.
De próbáljunk meg kevésbé technikai szempontból gondolkodni, vagyis próbáljuk meg elemezni az osztályunk vagy modulunk felhasználóját, azaz ki fogja használni. Alapvető szempont, amelyet mindig szem előtt kell tartanunk, az a tény, hogy az általunk fejlesztett alkalmazás vagy rendszer felhasználói, akiket egy adott modul szolgál ki, módosítást kérnek. A szolgálatot teljesítők kérni fogják az osztály vagy a modul megváltoztatását.
Néhány példa a modulokra és azok használatára:
Tehát, ha az első lépés a szereplők vagy a színész megkeresése, akinek a modullal beszélgetőpartneri szerepe van, az egyének társítása az összes szerephez nehéz lehet. Egy kis társaságban egy ember több szerepet is játszhat, míg egy nagy társaságban több ember is lehet, akiknek egyetlen szerepük van.
Ésszerűbbnek tűnik a szerepek azonosítása, nem pedig az emberek vagy a felhasználók.
Ezért:
Lássunk néhány példát
Tegyük fel, hogy van egy könyv osztályunk, amely összefoglalja a könyv fogalmát és annak funkcionalitását.
osztálykönyv {
függvény getTitle () {
visszatér egy „Nagy könyv”;
}
függvény getAuthor () {
visszatér Alessandro Baricco;
}
function nextpage () {
// következő oldal
}
függvény printCurrentPage () {
echo „az aktuális oldal tartalma”;
}
}
Ez egy nagyon normális osztály. Van egy könyvünk, és az osztály megadhatja a címet, megadhatja a szerzőt, és továbbléphetnek. Végül az aktuális oldal kinyomtatására is képes.
Van azonban egy kis probléma.
A Könyv objektum kezelésében részt vevő szereplőkre gondolva kik lehetnek?
Könnyen gondolhatunk itt két különböző szereplőre: Könyvkezelés (mint a könyvtáros) És Adatbeküldési mechanizmus (például hogyan szeretnénk tartalmat eljuttatni a felhasználóhoz: képernyőn, grafikus felhasználói felület, csak szöveges felhasználói felület, esetleg nyomtatás).
Ezért két nagyon különböző színész van interakcióban az osztállyal.
Dióhéjban ez az osztály keveréket alkot:
ez problémát jelenthet, mert sérti az egyetlen felelősség elvét (SRP).
Hogyan változtathatunk, hogyan javíthatjuk ezt a kódexet, hogy tiszteletben tartsuk az egyetlen felelősség elvét?
Vessen egy pillantást a következő kódra:
osztálykönyv {
függvény getTitle () {
vissza az „Oceano Mare”;
}
függvény getAuthor () {
visszatér Alessandro Baricco;
}
function turn page () {
// következő oldal
}
függvény getCurrentPage () {
echo „az aktuális oldal tartalma”;
}
}
interfész nyomtató {
függvény printPage ($ oldal);
}
osztályú StampaLibro nyomtatót hajt végre
függvény printPages ($ page) {
echo $ oldal;
}
}
class HtmlPrinter megvalósítja a nyomtatót {
függvény printPages ($ page) {
visszhang ”. $ oldal. " ";
}
}
Ez a nagyon egyszerű példa bemutatja, hogyan lehet elkülöníteni a prezentációt az üzleti logikától, és az SRP-vel összhangban nagy előnyökkel jár a projektünk rugalmasságában.
Nézzünk meg egy másik példát:
A fentihez hasonló példa, amikor egy objektum elmentheti és lekérheti magát a bemutatóból.
osztálykönyv {
függvény getTitle () {
vissza az „Oceano Mare”;
}
függvény getAuthor () {
visszatér Alessandro Baricco;
}
function turn page () {
// következő oldal
}
függvény getCurrentPage () {
return "az aktuális oldal tartalma";
}
function save () {
$ fájlnév = '/ dokumentumok /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ fájlnév, sorosítás ($ this));
}
}
Mint korábban, itt is azonosíthatunk különböző szereplőket Könyvkezelés (mint a könyvtáros) És Kitartás. Amikor meg akarjuk változtatni az oldalanként történő mozgást, meg kell változtatnunk ezt az osztályt. Számos oka lehet a változásnak.
osztálykönyv {
függvény getTitle () {
vissza az „Oceano Mare”;
}
függvény getAuthor () {
visszatér Alessandro Baricco;
}
function turn page () {
// következő oldal
}
függvény getCurrentPage () {
return "az aktuális oldal tartalma";
}
}
osztály SimpleFilePersistence {
függvény mentése (Book $ book) {
$ fájlnév = '/ dokumentumok /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();
file_put_contents ($ fájlnév, sorozatosítás ($ könyv));
}
}
A kitartási művelet áthelyezése egy másik osztályba egyértelműen elkülöníti a felelősségeket, és szabadon cserélhetjük a perzisztencia módszereket anélkül, hogy befolyásolnánk a könyv osztályunkat. Például egy DatabasePersistence osztály megvalósítása triviális lenne, és a könyvműveletek köré épített üzleti logikánk nem fog változni.
Folytassa a második elv nyitott / zárt -> elolvasásával
Ercole Palmeri
A Coveware by Veeam továbbra is nyújt kiberzsarolási incidensekre reagáló szolgáltatásokat. A Coveware kriminalisztikai és kármentesítési lehetőségeket kínál majd…
A prediktív karbantartás az üzemirányítás innovatív és proaktív megközelítésével forradalmasítja az olaj- és gázszektort.…
A brit CMA figyelmeztetést adott ki a Big Tech mesterséges intelligencia piacán tanúsított magatartása miatt. Ott…
Az Európai Unió által az épületek energiahatékonyságának fokozása érdekében megfogalmazott „Zöld Házak” rendelet a…
