|
|
Julkaistu 10.2.2019 18.14.29
|
|
|
Ensinnäkin luokkien toisiinsa liittyvien olioiden luominen voidaan todellakin toteuttaa uusilla. Kuitenkin, kun projekti on liian suuri ja oliolla on liikaa riippuvuuksia, meidän täytyy kirjoittaa paljon uutta koodia objektin rakentamisessa, ja voi olla tapa kutsua olio suoraan unohtamalla instantationsa riippuvista objekteista, jolloin syntyy nollaosoittimen poikkeus. Jos tämä prosessi jätetään konttien hallinnan hoidettavaksi, meidän ei tarvitse huolehtia objektien instanssioinnista, eikä null-osoittimen poikkeuksia tule riippuvaisia olioita käytettäessä, ja koodia voidaan yksinkertaistaa.
Toiseksi, metodikutsuprosessissa käytetyt attribuutit voivat olla instanssittribuutteja, ja jos ne kaikki määritellään staattisiksi, entä metodissa käytetty data? Jos määrittelet kaikki metodit staattisiksi, niin metodissa viitatun luokan ominaisuudet täytyy myös määritellä staattisiksi, mikä vastaa globaaleja attribuutteja, joten datan synkronointiongelmia tulee varmasti olemaan.
Itse asiassa on järkevää pohtia suunnittelumallissa annettuja ohjelmointiperiaatteita, jotka kaikki tähtäävät erittäin luettavan, helppoylläpidettävän ja skaalautuvan koodin rakentamiseen. Toivottaen!
On kätevää koota ohjelmistoja rakennuspalikoiden muodossa, ja on kätevää luoda ohjelmistoja, joissa on korkea koheesio ja vähäinen kytkentä (riippuvuuksien poimiminen koodista)
Yhteistyöhön perustuva kehitys, koodin virheenkorjaus (komponentteja ei tarvitse integroida yhteen, ne voidaan testata erikseen), ja luotu koodi on kestävämpää.
Projektin kehitys kiinnittää huomiota korkeaan koheesioon ja matalaan kytkentään, ja riippuvuusinjektion avulla voidaan välttää uuden avainsana-alueen käyttöä objektien luomiseen, mikä vähentää luokkien välistä kytkentää
|
Edellinen:c# Marshal.PtrToStructureSeuraava:Salaus, purku ja assembly-kieli
|
