Esiteks saab tõepoolest luua klasside seotud objekte. Kui projekt on aga liiga suur ja objektil on liiga palju sõltuvusi, peame objekti ehitamisel kirjutama palju uut koodi ning võib olla meetod, kuidas objekti otse kutsuda pärast seda, kui unustame mõne sõltuva objekti instantsieerida, siis tekib nullosuti erand. Kui see protsess jäetakse konteinerihalduse hooleks, ei pea me muretsema objektide loomise pärast ning sõltuvate objektide kasutamisel nullosuti erandeid ei tule ja koodi saab lihtsustada.
Teiseks, meetodi kutsumise protsessis kasutatavad atribuudid võivad olla eksemplari atribuudid, kui need kõik on defineeritud staatiliseks, siis kuidas on lood meetodis kasutatavate andmetega? Kui defineerida kõik meetodid staatiliseks, siis peavad meetodis viidatud klassi omadused samuti olema staatilised, mis on ekvivalentne globaalsete atribuutidega, seega tekivad kindlasti andmete sünkroniseerimise probleemid.
Tegelikult on mõistlik mõelda disainimustris toodud programmeerimispõhimõtetele, mis kõik on suunatud väga loetava, lihtsasti hooldatava ja skaleeritava koodi loomisele. Parimate soovidega!
On mugav koostada tarkvara ehitusplokkide kujul ning on mugav luua tarkvara, millel on kõrge sidusus ja madal sidumine (sõltuvuste eraldamine koodist)
Koostööpõhine arendus, silumiskood (komponente pole vaja omavahel integreerida, neid saab eraldi testida) ja loodud kood on vastupidavam.
Projektiarendus pöörab tähelepanu kõrgele sidususele ja madalale sidumisele ning sõltuvussüstimise kasutamine aitab vältida uue märksõnaala kasutamist objektide loomiseks, vähendades seeläbi klassidevahelist sidumist
|
Postitatud 10.02.2019 18:14:29
|
|
|
