För det första kan skapandet av relaterade objekt för klasser faktiskt göras av nya. Men när projektet är för stort och objektet har för många beroenden behöver vi skriva mycket ny kod när vi bygger objektet, och det kan finnas en metod där objektet direkt anropas efter att man glömt att instansiera vissa beroende objekt, då uppstår ett nullpekarundantag. Om denna process lämnas till containerhantering behöver vi inte oroa oss för objektinstansiering, och det kommer inte att finnas några nullpekarundantag vid användning av beroende objekt vid någon tidpunkt, och koden kan förenklas.
För det andra kan attributen som används i metodanropsprocessen vara instansattribut, om de alla definieras som statiska, hur är det då med datan som används i metoden? Om du definierar alla metoder som statiska, måste egenskaperna hos klassen som refereras till i metoden också definieras som statiska, vilket motsvarar globala attribut, så det kommer definitivt att finnas problem med datasynkronisering.
Faktum är att det är logiskt att fundera på programmeringsprinciperna som ges i designmönstret, alla inriktade på att bygga mycket läsbar, lättunderhålllig och skalbar kod. Varmaste lyckönskningar!
Det är bekvämt att montera mjukvara som byggstenar, och det är bekvämt att skapa programvara med hög kohesion och låg koppling (genom att extrahera beroenden från koden)
Samarbetsutveckling, felsökning av kod (ingen integration av komponenter, de kan testas separat), och koden som skapas är mer robust.
Projektutveckling lägger stor vikt vid hög kohesion och låg koppling, och användningen av beroendeinjektion kan undvika att använda det nya nyckelordsområdet för att skapa objekt, vilket därmed minskar kopplingen mellan klasser
|
Publicerad på 2019-02-10 18:14:29
|
|
|
