În primul rând, crearea obiectelor înrudite ale claselor poate fi într-adevăr realizată de noi. Totuși, când proiectul este prea mare și obiectul are prea multe dependențe, trebuie să scriem mult cod nou la construirea obiectului, iar poate exista o metodă de a chema direct obiectul după ce ai uitat să instanțieze unele obiecte dependente, atunci va exista o excepție pentru pointer nul. Dacă acest proces este lăsat în seama gestionării containerelor, nu trebuie să ne facem griji pentru instanțierea obiectelor și nu vor exista excepții de pointer nul când se folosesc obiecte dependente în niciun moment, iar codul poate fi simplificat.
În al doilea rând, atributele folosite în procesul de apelare a metodei pot fi atribute de instanță; dacă toate sunt definite ca statice, ce se întâmplă cu datele folosite în metodă? Dacă definești toate metodele ca statice, atunci proprietățile clasei referențiate în metodă trebuie să fie definite și ele ca statice, ceea ce este echivalent cu atributele globale, deci vor exista cu siguranță probleme de sincronizare a datelor.
De fapt, are sens să ne gândim la principiile de programare prezentate în modelul de proiectare, toate menite să construiască cod foarte lizibil, ușor de întreținut și scalabil. Cele mai bune urări!
Este convenabil să asamblezi software-ul sub forma unor blocuri de construcție și este convenabil să creezi software cu coeziune ridicată și cuplaj scăzut (extragând dependențe din cod)
Dezvoltarea colaborativă, depanarea codului (nu este nevoie să integrezi componente, pot fi testate separat), iar codul creat este mai robust.
Dezvoltarea proiectului acordă atenție coeziunii ridicate și cuplării scăzute, iar utilizarea injecției de dependență poate evita folosirea noii zone de cuvinte-cheie pentru a crea obiecte, reducând astfel cuplarea dintre clase
|
Postat pe 10.02.2019 18:14:29
|
|
|
