Pirmkārt, saistītu klašu objektu izveidi patiešām var veikt jauns. Tomēr, ja projekts ir pārāk liels un objektam ir pārāk daudz atkarību, veidojot objektu, mums ir jāraksta daudz jauna koda, un var būt metode, kā tieši izsaukt objektu pēc tam, kad aizmirsāt izveidot dažus atkarīgus objektus, tad būs nulles rādītāja izņēmums. Ja šis process tiek atstāts konteineru pārvaldībai, mums nav jāuztraucas par objektu instancēšanu, un, izmantojot atkarīgos objektus, jebkurā laikā nebūs nulles rādītāja izņēmumu, un kodu var vienkāršot.
Otrkārt, metodes izsaukšanas procesā izmantotie atribūti var būt instances atribūti, ja tie visi ir definēti kā statiski, kā ar metodē izmantotajiem datiem? Ja visas metodes definējat kā statiskas, tad metodē norādītās klases īpašības ir jādefinē arī kā statiskas, kas ir līdzvērtīgas globālajiem atribūtiem, tāpēc noteikti būs datu sinhronizācijas problēmas.
Patiesībā ir jēga domāt par programmēšanas principiem, kas norādīti dizaina modelī, kuru mērķis ir izveidot ļoti lasāmu, viegli uzturamu un mērogojamu kodu. Laimes vēlējums!
Ir ērti salikt programmatūru veidošanas bloku veidā, un ir ērti izveidot programmatūru ar augstu kohēziju un zemu savienojumu (atkarību iegūšana no koda)
Sadarbības izstrāde, atkļūdošanas kods (nav nepieciešams integrēt komponentus kopā, tos var pārbaudīt atsevišķi), un izveidotais kods ir spēcīgāks.
Projekta izstrādē uzmanība tiek pievērsta augstai kohēzijai un zemai savienošanai, un atkarības injekcijas izmantošana var izvairīties no jaunā atslēgvārda apgabala izmantošanas objektu izveidei, tādējādi samazinot sasaisti starp klasēm
|
Publicēts 10.02.2019 18:14:29
|
|
|
