Prvič, ustvarjanje sorodnih objektov razredov je res mogoče izvesti z novimi. Vendar pa, ko je projekt prevelik in ima objekt preveč odvisnosti, moramo pri gradnji objekta napisati veliko nove kode, in morda obstaja metoda za neposredno klicanje objekta, potem ko pozabimo instancirati nekatere odvisne objekte, potem bo prišlo do izjeme ničelnega kazaleca. Če je ta proces prepuščen upravljanju kontejnerjev, nam ni treba skrbeti za instanciranje objektov, prav tako ne bo izjem ničelnega kazalca pri uporabi odvisnih objektov kadarkoli, koda pa je lahko poenostavljena.
Drugič, atributi, ki se uporabljajo v procesu klica metode, so lahko atributi instance; če so vsi definirani kot statični, kaj pa podatki, uporabljeni v metodi? Če vse metode definirate kot statične, potem morajo biti lastnosti razreda, na katerega se metoda sklicuje, prav tako definirane kot statične, kar je ekvivalentno globalnim atributom, zato bodo zagotovo težave s sinhronizacijo podatkov.
Pravzaprav je smiselno razmisliti o programskih načelih, podanih v oblikovalskem vzorcu, ki so vsi usmerjeni v gradnjo zelo berljive, enostavne za vzdrževanje in razširljive kode. Z najboljšimi željami!
Priročno je sestavljati programsko opremo v obliki gradnikov, prav tako pa je priročno ustvarjati programsko opremo z visoko kohezijo in nizko povezanostjo (izvlečenje odvisnosti iz kode)
Sodelovalni razvoj, razhroščevanje kode (ni potrebe po integraciji komponent, ki jih je mogoče testirati ločeno) in ustvarjena koda so bolj robustni.
Razvoj projektov daje pozor visoki koheziji in nizki povezanosti, uporaba injekcije odvisnosti pa lahko prepreči uporabo novega območja ključnih besed za ustvarjanje objektov, s čimer se zmanjša povezanost med razredi
|
Objavljeno na 10. 02. 2019 18:14:29
|
|
|
