For det første kan opprettelsen av relaterte objekter for klasser faktisk gjøres av nye. Men når prosjektet er for stort og objektet har for mange avhengigheter, må vi skrive mye ny kode når vi bygger objektet, og det kan finnes en metode for å direkte kalle objektet etter å ha glemt å instansiere noen avhengige objekter, da vil det være et nullpeker-unntak. Hvis denne prosessen overlates til containerhåndtering, trenger vi ikke bekymre oss for objektinstansiering, og det vil ikke være nullpekerunntak når man bruker avhengige objekter til enhver tid, og koden kan forenkles.
For det andre kan attributtene som brukes i metodekall-prosessen være instansattributter; hvis de alle er definert som statiske, hva med dataene som brukes i metoden? Hvis du definerer alle metoder som statiske, må egenskapene til klassen som refereres til i metoden også defineres som statiske, noe som tilsvarer globale attributter, så det vil definitivt oppstå problemer med datasynkronisering.
Faktisk gir det mening å tenke på programmeringsprinsippene gitt i designmønsteret, alle med mål om å bygge svært lesbar, lett å vedlikeholde og skalerbar kode. De beste ønsker!
Det er praktisk å sette sammen programvare i form av byggeklosser, og det er praktisk å lage programvare med høy kohesjon og lav kobling (ved å trekke ut avhengigheter fra koden)
Samarbeidende utvikling, feilsøking av kode (ingen grunn til å integrere komponenter sammen, de kan testes separat), og koden som lages er mer robust.
Prosjektutvikling legger vekt på høy kohesjon og lav kobling, og bruk av avhengighetsinjeksjon kan unngå å bruke det nye nøkkelordområdet for å lage objekter, og dermed redusere koblingen mellom klasser
|
Publisert på 10.02.2019 18:14:29
|
|
|
