Először is, az osztályok kapcsolódó objektumainak létrehozása valóban megvalósítható új tárgyakkal. Azonban, ha a projekt túl nagy és túl sok függősége van, rengeteg új kódot kell írnunk az objektum építésekor, és lehet, hogy létezik egy módszer, amely közvetlenül meghívja az objektumot, miután elfelejtünk néhány függő objektumot megidézni, akkor null mutató kivétel lesz. Ha ezt a folyamatot a konténerkezelésre bízzuk, nem kell aggódnunk az objektum megbocsátása miatt, és bármikor nem lesznek null pointer kivételek, ha függő objektumokat használunk, így a kód egyszerűsíthető.
Másodszor, a metódushívási folyamatban használt attribútumok lehetnek instance attribútumok, ha mind statikus állapotúak, mi a helyzet a metódusban használt adatokkal? Ha minden metódust statikusnak definiálsz, akkor a metódusban hivatkozott osztály tulajdonságait is statikusnak kell definiálni, ami ekvivalens a globális attribútumokkal, így biztosan lesznek adatszinkronizációs problémák.
Valójában érdemes átgondolni a tervezési mintában megadott programozási elveket, amelyek mind a nagyon olvasható, könnyen karbantartott és skálázható kód létrehozására irányulnak. A legjobbakat!
Kényelmes szoftverek összeállítása építőelemek formájában, és kényelmes olyan szoftvereket készíteni, amelyek magas kohézióval és alacsony kapcsolódással rendelkeznek (függőségek kinyerése a kódból)
Együttműködésen alapuló fejlesztés, hibakeresés kód (nem szükséges integrálni az alkatrészeket, külön-külön tesztelhetők), és a létrehozott kód robusztusabb.
A projektfejlesztés nagy kohézióra és alacsony kapcsolódásra figyel, és a függőségi injekció alkalmazása elkerülheti, hogy az új kulcsszóterület objektumok létrehozásához használhassa, így csökkentve az osztályok közötti kapcsolódást
|
Közzétéve 2019. 02. 10. 18:14:29
|
|
|
