For det første kan oprettelsen af relaterede objekter for klasser faktisk gøres af nye. Men når projektet er for stort, og objektet har for mange afhængigheder, skal vi skrive en masse ny kode, når vi bygger objektet, og der kan være en metode til direkte at kalde objektet efter at have glemt at instansiere nogle afhængige objekter, og så vil der være en nullpointer-undtagelse. Hvis denne proces overlades til containerstyring, behøver vi ikke bekymre os om objektinstansiering, og der vil ikke være nulpointer-undtagelser ved brug af afhængige objekter på noget tidspunkt, og koden kan forenkles.
For det andet kan de attributter, der bruges i metodekaldsprocessen, være instansattributter; hvis de alle er defineret som statiske, hvad med de data, der bruges i metoden? Hvis du definerer alle metoder som statiske, skal egenskaberne for klassen, der refereres til i metoden, også defineres som statiske, hvilket svarer til globale attributter, så der vil helt sikkert være problemer med datasynkronisering.
Faktisk giver det mening at tænke over programmeringsprincipperne i designmønsteret, som alle har til formål at bygge meget læsbar, let vedligeholdelses- og skalerbar kode. De bedste ønsker!
Det er praktisk at samle software som byggesten, og det er praktisk at skabe software med høj kohæsion og lav kobling (udtrækning af afhængigheder fra koden)
Samarbejdsudvikling, fejlfinding af kode (ingen grund til at integrere komponenter sammen, de kan testes separat), og den kode, der skabes, er mere robust.
Projektudvikling lægger vægt på høj kohæsion og lav kobling, og brugen af afhængighedsinjektion kan undgå at bruge det nye nøgleordsområde til at skabe objekter, hvilket dermed reducerer koblingen mellem klasser
|
Opslået på 10/02/2019 18.14.29
|
|
|
