Pirma, susijusių klasių objektų kūrimas iš tiesų gali būti atliekamas naujais. Tačiau kai projektas yra per didelis ir objektas turi per daug priklausomybių, kurdami objektą turime parašyti daug naujo kodo, o pamiršus sukurti kai kuriuos priklausomus objektus gali būti būdas tiesiogiai iškviesti objektą, tada bus nulinė žymeklio išimtis. Jei šis procesas bus paliktas konteinerių valdymui, mums nereikės jaudintis dėl objektų instanciacijos, o naudojant priklausomus objektus bet kuriuo metu nebus nulinių žymeklio išimčių, o kodą galima supaprastinti.
Antra, metodo iškvietimo procese naudojami atributai gali būti egzemplioriaus atributai, jei jie visi apibrėžiami kaip statiniai, o kaip su metode naudojamais duomenimis? Jei visus metodus apibrėžiate kaip statinius, tada metode nurodytos klasės savybės taip pat turi būti apibrėžtos kaip statinės, o tai atitinka globalius atributus, todėl tikrai kils duomenų sinchronizavimo problemų.
Tiesą sakant, prasminga galvoti apie programavimo principus, pateiktus dizaino modelyje, kuriais siekiama sukurti labai skaitomą, lengvai prižiūrimą ir keičiamo dydžio kodą. Geriausi linkėjimai!
Patogu surinkti programinę įrangą statybinių blokų būdu, taip pat patogu kurti programinę įrangą su didele sanglauda ir mažu sujungimu (ištraukiant priklausomybes iš kodo)
Bendradarbiavimo kūrimas, derinamas kodas (nereikia integruoti komponentų kartu, juos galima išbandyti atskirai), o sukurtas kodas yra tvirtesnis.
Kuriant projektą atkreipiamas dėmesys į didelę sanglaudą ir mažą susiejimą, o naudojant priklausomybės injekciją galima išvengti naujos raktinių žodžių srities naudojimo objektams kurti, taip sumažinant klasių susiejimą
|
Paskelbta 2019-02-10 18:14:29
|
|
|
