Ten eerste kan het creëren van gerelateerde objecten van klassen inderdaad door nieuwe gedaan worden. Wanneer het project echter te groot is en het object te veel afhankelijkheden heeft, moeten we veel nieuwe code schrijven bij het bouwen van het object, en er kan een methode zijn om het object direct aan te roepen nadat je vergeten bent sommige afhankelijke objecten te instantiëren, waarna er een nullpointer-uitzondering ontstaat. Als dit proces aan containerbeheer wordt overgelaten, hoeven we ons geen zorgen te maken over objectinstantie, en zijn er geen nullpointer-uitzonderingen bij gebruik van afhankelijke objecten op enig moment, en kan de code worden vereenvoudigd.
Ten tweede kunnen de attributen die in het method call-proces worden gebruikt instantieattributen zijn; als ze allemaal als statisch worden gedefinieerd, hoe zit het dan met de data die in de methode wordt gebruikt? Als je alle methoden als statisch definieert, dan moeten de eigenschappen van de klasse waarnaar in de methode wordt verwezen ook statisch zijn, wat gelijkstaat aan globale attributen, dus er zullen zeker problemen zijn met data-synchronisatie.
Het is zelfs logisch om na te denken over de programmeerprincipes die in het ontwerppatroon worden gegeven, allemaal gericht op het bouwen van zeer leesbare, gemakkelijk te onderhouden en schaalbare code. Beste wensen!
Het is handig om software te assembleren in de vorm van bouwstenen, en het is handig om software te maken met hoge cohesie en lage koppeling (waarbij afhankelijkheden uit de code worden gehaald)
Samenwerkende ontwikkeling, code debuggen (componenten hoeven niet met elkaar te integreren, ze kunnen apart getest worden), en de gemaakte code is robuuster.
Projectontwikkeling let op hoge cohesie en lage koppeling, en het gebruik van afhankelijkheidsinjectie kan voorkomen dat het nieuwe trefwoordgebied wordt gebruikt om objecten te creëren, waardoor de koppeling tussen klassen wordt verminderd
|
Geplaatst op 10-02-2019 18:14:29
|
|
|
