Gyakran találkozom olyan fejlesztőkkel, akik még nem hallottak a SOLID-elvekről (itt . — A szerk.) vagy az objektum-orientált programozásról (OOP), esetleg hallottak róla, de nem alkalmazzák őket a gyakorlatban. Ez a cikk az OOP elveinek előnyeit tárgyalja, amelyek segítik a fejlesztőket mindennapi munkájukban. Néhány elv jól ismert, mások talán nem annyira, így a cikk hasznos lesz mind a kezdők, mind a tapasztalt programozók számára.
Emlékeztetjük: Minden »Habr« olvasónak — 10 000 forint kedvezmény bármely Skillbox tanfolyamra a »Habr« promóciós kóddal.
A Skillbox ajánlja: Oktatási online kurzus .
DRY (Don’t Repeat Yourself)
Ez egy elég egyszerű elv, amelynek lényege világos a nevéből: „Ne ismételd meg magad”. A programozó számára ez azt jelenti, hogy el kell kerülni a duplikált kódot, valamint lehetőséget kell adni az absztrakció használatára a munkában.
Ha a kódban két ismétlődő szakasz található, érdemes összegyűjteni őket egy metódusba. Ha egy merev érték többször is használatra kerül, akkor érdemes közpublic változóvá alakítani.
Ez szükséges ahhoz, hogy egyszerűsítsük a kódot és könnyebbé tegyük a karbantartását, ami az OOP alapvető célja. Túlzásba sem érdemes vinni az összegzést, mivel a már ugyanaz a kód nem fog működni az OrderId-val és az SSN-nel is.
A változások inkapszulálása
A legtöbb cég szoftvertermékei folyamatosan fejlődnek. Ezért a kódban változtatásokat kell eszközölni, karbantartani kell azt. Az élete egyszerűsítése érdekében az inkapszulációt használhatjuk. Ez lehetővé teszi a meglévő kódalap hatékonyabb tesztelését és karbantartását. .
Ha Java-ban programozol, akkor .
Nyitottság/zárottság elve
Ezt az elvet könnyen megjegyezhetjük, ha elolvassuk a következő kijelentést: „A programozási entitások (osztályok, modulok, függvények stb.) nyitottak kell, hogy legyenek a bővítésre, de zártak a módosításra”. A gyakorlatban ez azt jelenti, hogy lehetővé kell tenniük a viselkedésük megváltoztatását a forráskód megváltoztatása nélkül.
Ez az elv fontos, amikor a forráskód módosításai átfogó felülvizsgálatot, moduláris tesztelést és egyéb eljárásokat igényelnek. Az a kód, amely az nyitottság/zárottság elvének megfelelően működik, nem változik meg bővítéskor, így ezzel lényegesen kevesebb probléma merül fel.
Íme egy kód példa, amely megsérti ezt az elvet.
Ha szükséges bármilyen módosítást végezni, az sok időt vehet igénybe, mivel az összes olyan kódrészletet módosítani kell, amely kapcsolatban áll a szükséges résszel.
Egyébként a nyitottság-zártság a SOLID alapelvek egyike.
Egységes felelősség elve (SRP)
Ez egy másik elv a SOLID csoportból. Azt mondja, hogy "csak egyetlen ok van, ami miatt egy osztályt módosítani kell". Az osztály kizárólag egy feladat megoldására vonatkozik. Több metódusa lehet, de ezek közül mindegyik csak a közös feladat megoldására szolgál. Minden metódusnak és tulajdonságnak csak ezt kell szolgálnia.
Ennek az elvnek az értéke abban rejlik, hogy gyengíti a kapcsolatot a szoftver egyes komponensei és a kód között. Ha egy osztályba több mint egy funkciót adunk, az a két funkció közötti kapcsolat kialakulását jelenti. Így ha az egyik megváltozik, nagy a valószínűsége, hogy a másik, az elsőhöz kapcsolódó is megsérül. Ez pedig a tesztelési ciklusok növekedését jelenti, hogy előre észleljük az összes problémát.
Függőségek inverziója elve (DIP)
Fent egy kódpéldát látunk, ahol az AppManager az EventLogWriter-től függ, amely szorosan kapcsolódik az AppManagerhez. Ha más módon kell értesítést küldeni, legyen az push, SMS vagy e-mail, meg kell változtatni az AppManager osztályt.
A problémát DIP segítségével lehet megoldani. Így az AppManager helyett kérjük az EventLogWriter-t, amely a keretrendszeren keresztül kerül bevezetésre.
A DIP lehetővé teszi egyes modulok hibamentes helyettesítését másokkal, megváltoztatva a függőségi modult. Ez lehetővé teszi egy modul módosítását anélkül, hogy az másokra hatással lenne.
Kompozíció öröklődés helyett
A kód újrahasználatának két alapvető módja van - az öröklés és a kompozíció, mindkettőnek vannak előnyei és hátrányai. Általában a másodikat részesítik előnyben, mivel rugalmasabb.
A kompozíció lehetővé teszi az osztály viselkedésének megváltoztatását futásidőben a tulajdonságainak beállításával. Az interfészek implementálásakor a polimorfizmust használjuk, amely rugalmasabb implementációt ad.
Még Joshua Bloch "Effective Java" című könyvében is a kompozíciót javasolja az örökléssel szemben.
Barbara Liskov helyettesítési elve (LSP)
A SOLID principle. It states that subtypes should be substitutable for their base types. This means that methods and functions that work with the superclass should also work seamlessly with its subclasses.
LSP is related to both the single responsibility principle and the interface segregation principle. If a class offers more functionality than its subclass, the latter will not support some of the functions, violating this principle.
Here is a piece of code that contradicts LSP.
The method area(Rectangle r) calculates the area of a Rectangle. The program will crash when executed with Square, as Square is not a Rectangle in this context. According to LSP, functions that use references to base classes should be able to use derived class objects without additional instructions.
This principle, which is a specific definition of subtype, was proposed by Barbara Liskov in 1987 at a conference in her keynote address titled 'Data Abstraction and Hierarchy' — hence its name.
Interface Segregation Principle (ISP)
Another SOLID principle. It states that an interface that isn't used should not be implemented. Adhering to this principle helps keep the system flexible and suitable for refactoring when changes in logic are needed.
This situation most often arises when an interface contains several functionalities, while the client only needs one of them.
Since writing an interface is a complex task, modifying it after completion without breaking anything will be challenging.
The advantage of the ISP in Java is that all methods must be implemented before they can be used by the classes. Therefore, this principle allows for a reduction in the number of methods.
Programming for the interface, not the implementation
This is clear from the title. Applying this principle leads to the creation of flexible code that can work with any new implementation of the interface.
You should use the interface type for variables, return types, or method argument types. For example — use SuperClass instead of SubClass.
That is:
List numbers = getNumbers();
Not:
ArrayList numbers = getNumbers();
Here is a practical implementation of what is described above.
A delegálás elve
Egy gyakori példa az equals() és hashCode() módszerek a Java-ban. Amikor két objektumot kell összehasonlítani, ez a művelet a megfelelő osztálynak delegálódik a kliens helyett.
A elv előnye a kód ismétlődésének hiánya és a viselkedés viszonylag egyszerű módosíthatósága. Emellett alkalmazható események delegálására is.
Mindezek az elvek lehetővé teszik rugalmasabb, szebb és megbízhatóbb kód írását, magas összetartozással és alacsony kötődéssel. Nyilvánvaló, hogy a teória hasznos, de ahhoz, hogy a fejlesztő tényleg alkalmazni tudja a megszerzett tudást, gyakorlásra van szükség. A következő lépés az OOP alapelveinek elsajátítása után lehet a tervezési minták tanulmányozása, amelyek általános szoftverfejlesztési problémák megoldására szolgálnak.
A Skillbox ajánlja:
- Gyakorlati kurzus .
- Alkalmazott online kurzus .
- Kétéves gyakorlati tanfolyam .
Forrás: habr.com
