Programavimas

Dizainas pokyčiams: susiejimas ir sujungimas į objektą orientuotose sistemose

Susiejimas ir sanglauda yra du dažnai neteisingai suprantami programinės įrangos inžinerijos terminai. Tai yra terminai, kurie naudojami kokybinei sistemos moduliarumo analizei nurodyti, ir jie padeda mums nustatyti ir išmatuoti į objektą orientuotų sistemų projektavimo sudėtingumą.

Tačiau norint sukurti sistemas, kurios būtų keičiamos, valdomos ir kurias būtų galima išplėsti laikui bėgant, reikia gerai žinoti abi puses. Šiame pranešime aptarsiu abu šiuos dalykus; Pateiksiu kodų pavyzdžius savo būsimuose įrašuose šia tema.

Kuo skiriasi sanglauda ir susiejimas? Kaip sąvokų sanglauda ir susiejimas yra susijęs su geru ar prastu programinės įrangos dizainu? Prieš tyrinėdami sanglaudą ir susiejimą bei jų įtaką programinės įrangos projektavimui, supraskime, kas yra kiekviena iš šių sąvokų ir jų rūšys.

Sukabinimas

Susiejimas gali būti apibrėžiamas kaip programinės įrangos modulių tarpusavio priklausomybės laipsnis ir jų glaudus tarpusavio ryšys. Iš esmės susiejimas rodo programinės įrangos modulių tarpusavio ryšio stiprumą. Kai šis susiejimas yra didelis, galime manyti, kad programinės įrangos moduliai yra tarpusavyje priklausomi, ty jie negali veikti be kito. Yra keli sukabinimo matmenys:

  • Turinio susiejimas - tai sujungimo tipas, kai tam tikras modulis gali pasiekti ar modifikuoti bet kurio kito modulio turinį. Iš esmės, kai komponentas perduoda parametrus tam, kad valdytų kito komponento aktyvumą, tarp dviejų komponentų yra valdymo jungtis.
  • Bendras sujungimas - tai sujungimo tipas, kai turite kelis modulius, turinčius prieigą prie bendrų visuotinių duomenų
  • Antspaudų sujungimas - tai sujungimo tipas, kai duomenų struktūra naudojama informacijai perduoti iš vieno sistemos komponento į kitą
  • Valdymo jungtis - tai jungties tipas, kurio vienas modulis gali pakeisti kito modulio vykdymo srautą
  • Duomenų sujungimas - tokio tipo sujungimo metu du moduliai sąveikauja keisdamiesi arba perduodami duomenis kaip parametrą

Sanglauda

Sanglaida žymi programinės įrangos modulio elementų priklausomybės nuo vidaus lygį. Kitaip tariant, sanglauda yra matas, kiek vieno modulio ar komponento atsakomybė sudaro reikšmingą vienetą. Sanglauda yra šių tipų:

  • Atsitiktinė sanglauda - tai neplanuota atsitiktinė sanglauda, ​​kuri gali atsirasti suskaidžius modulį į mažesnius modulius.
  • Loginė sanglauda - tai sanglaudos tipas, kai į tą patį komponentą dedamos kelios logiškai susijusios funkcijos ar duomenų elementai
  • Laikina sanglauda - tai sanglaudos rūšis, kai modulio elementai yra grupuojami taip, kaip jie apdorojami tuo pačiu laiko momentu. Pavyzdys gali būti komponentas, naudojamas inicializuoti objektų rinkinį.
  • Procedūrinė sanglauda - tai sanglaudos rūšis, kai komponento funkcijos sugrupuojamos taip, kad jas būtų galima vykdyti nuosekliai ir kad jos būtų procedūriškai darnios
  • Komunikacinė sanglauda - šio tipo sanglaudoje modulio elementai yra logiškai sugrupuoti taip, kad jie būtų vykdomi nuosekliai ir jie dirbtų su tais pačiais duomenimis
  • Nuoseklioji sanglauda - šio tipo sanglaudoje modulio elementai yra sugrupuoti taip, kad vieno iš jų išvestis tampa kito įvestimi - jie visi vykdomi nuosekliai. Iš esmės, jei vienos komponento dalies išvestis yra kitos įvestis, sakome, kad komponentas turi nuoseklų nuoseklumą.
  • Funkcinė sanglauda - tai geriausia ir labiausiai pageidaujama sanglaudos rūšis, kurioje sanglaudos laipsnis yra didžiausias. Šio tipo sanglaudoje modulio elementai yra funkciškai sugrupuoti į loginį vienetą ir jie veikia kartu kaip loginis vienetas - tai taip pat skatina lankstumą ir pakartotinį naudojimą.

Geriausia praktika

Griežtas sujungimas padidina priežiūros išlaidas, nes tai yra sunku, o vieno komponento pakeitimai paveiktų visus kitus prie jo prijungtus komponentus. Taigi kodo pertvarkymas tampa sudėtingas, nes jums reikės pertvarkyti visus kitus prijungtos grandinės komponentus, kad funkcionalumas nenutrūktų. Šis procesas yra sudėtingas ir reikalauja daug varginančių pastangų ir laiko.

Turėtumėte kurti klases, kuriose yra mažiau egzempliorių kintamųjų, t. Y. Jūsų klasės dizainas yra „geras“, jei jame yra nedaug egzempliorių kintamųjų. Geriausia, jei kiekvienas jūsų klasės metodas turėtų manipuliuoti vienu ar keliais iš šių kintamųjų. Teoriškai klasė yra maksimaliai darni, jei kiekvienas klasės egzempliorių kintamasis naudojamas arba jais manipuliuojama kiekvienu tos klasės metodu. Kai sanglauda klasėje yra aukšta, metodai ir klasės duomenys yra priklausomi ir veikia kartu kaip vienas loginis vienetas. Tačiau iš tikrųjų neįmanoma sukurti tokių klasių arba aš norėčiau pasakyti, kad nepatartina kurti klasių, kurios būtų kuo labiau suderintos.

$config[zx-auto] not found$config[zx-overlay] not found