Първо, създаването на свързани обекти на класове наистина може да се осъществи от нови. Въпреки това, когато проектът е твърде голям и обектът има твърде много зависимости, трябва да напишем много нов код при изграждането му, и може да има метод за директно извикване на обекта след забравяне да се инстанцират някои зависими обекти, тогава ще има изключение за null pointer. Ако този процес бъде оставен на управлението на контейнера, не трябва да се притесняваме за инстанциация на обекти, няма да има изключения от null pointer при използване на зависими обекти по всяко време, а кодът може да бъде опростен.
Второ, атрибутите, използвани в процеса на извикване на метод, могат да бъдат атрибути на екземпляра, ако всички са дефинирани като статични, какво да кажем за данните, използвани в метода? Ако дефинирате всички методи като статични, тогава свойствата на класа, посочен в метода, също трябва да бъдат дефинирани като статични, което е еквивалентно на глобалните атрибути, така че със сигурност ще има проблеми със синхронизацията на данните.
Всъщност има смисъл да се помисли за програмните принципи, заложени в дизайн шаблона, всички насочени към изграждане на високо четлив, лесен за поддръжка и мащабируем код. Най-добри пожелания!
Удобно е да се сглобява софтуер като градивни блокове, както и да се създава софтуер с висока кохезия и ниска свързаност (извличане на зависимости от кода)
Съвместна разработка, дебъгване на код (няма нужда да се интегрират компоненти заедно, те могат да се тестват отделно), а създаденият код е по-стабилен.
Разработването на проекти обръща внимание на висока кохезия и ниска свързаност, а използването на инжекция на зависимости може да избегне използването на новата ключова дума за създаване на обекти, като по този начин намалява връзката между класовете
|
Публикувано в 10.02.2019 г. 18:14:29 ч.
|
|
|
