Programmering

Design for endring: Kobling og kohesjon i objektorienterte systemer

Kobling og kohesjon er to ofte misforståtte begreper innen programvareteknikk. Dette er begreper som brukes til å indikere den kvalitative analysen av modulariteten i et system, og de hjelper oss med å identifisere og måle designkompleksiteten til objektorienterte systemer.

Imidlertid er god kunnskap om begge deler nødvendig for å bygge systemer som er skalerbare, håndterbare og kan utvides over tid. I dette innlegget vil jeg diskutere begge disse; Jeg vil presentere kodeeksempler i mine fremtidige innlegg om dette emnet.

Hvordan er sammenheng og kobling forskjellige? Hvordan er begrepene kohesjon og kobling relatert til god eller dårlig programvaredesign? Før vi utforsker samhørighet og kobling og hvordan de påvirker programvaredesign, la oss forstå hva hvert av disse konseptene er og deres typer.

Kobling

Kobling kan defineres som graden av gjensidig avhengighet som eksisterer mellom programvaremoduler og hvor nært de er koblet til hverandre. I hovedsak indikerer kobling styrken av sammenkoblingen mellom programvaremoduler. Når denne koblingen er høy, kan vi anta at programvaremodulene er gjensidig avhengige, dvs. de kan ikke fungere uten den andre. Det er flere dimensjoner på koblingen:

  • Innholdskobling - dette er en type kobling der en bestemt modul kan få tilgang til eller endre innholdet i en hvilken som helst annen modul. I hovedsak, når en komponent passerer parametere for å kontrollere aktiviteten til en annen komponent, er det en kontrollkobling mellom de to komponentene.
  • Vanlig kobling - dette er en type kobling der du har flere moduler som har tilgang til delte globale data
  • Stempelkobling - dette er en type kobling der datastrukturen brukes til å overføre informasjon fra en komponent i systemet til en annen
  • Kontrollkobling - dette er en type kobling der en modul kan endre gjennomføringsflyten til en annen modul
  • Datakobling - i denne typen kobling samhandler to moduler ved å utveksle eller sende data som en parameter

Samhold

Samhold tyder på nivået av avhengighet blant elementene i en programvaremodul. Med andre ord er kohesjon et mål på i hvilken grad ansvaret til en enkelt modul eller en komponent danner en meningsfull enhet. Samhold er av følgende typer:

  • Co-tilfeldig kohesjon - dette er en ikke-planlagt tilfeldig kohesjon som kan være et resultat av å bryte en modul i mindre moduler.
  • Logisk kohesjon - dette er en type kohesjon der flere logisk relaterte funksjoner eller dataelementer er plassert i samme komponent
  • Temporal kohesjon - dette er en type kohesjon der elementene i en modul er gruppert på en måte de behandles på samme tidspunkt. Et eksempel kan være en komponent som brukes til å initialisere et sett med objekter.
  • Prosessuell kohesjon - dette er en type kohesjon der funksjonene i en komponent er gruppert på en måte som gjør det mulig å utføre dem sekvensielt og gjøre dem prosessuelt sammenhengende
  • Kommunikasjonssammenheng - i denne typen samhold er elementene i en modul logisk gruppert sammen på en måte som de utfører sekvensielt, og de jobber med de samme dataene
  • Sekvensiell kohesjon - i denne typen kohesjon er elementene i en modul gruppert på en slik måte at utgangen til en av dem blir inngangen til den neste - de utføres alle sekvensielt. I hovedsak, hvis utdataene fra en del av en komponent er inngangen til en annen, sier vi at komponenten har sekvensiell kohesjon.
  • Funksjonell kohesjon - dette er den beste og mest foretrukne typen kohesjon der kohesjonsgraden er høyest. I denne typen kohesjon er elementene i en modul funksjonelt gruppert i en logisk enhet, og de fungerer sammen som en logisk enhet - dette fremmer også fleksibilitet og gjenbrukbarhet.

De beste metodene

Tett kobling øker vedlikeholdskostnadene ettersom det er vanskelig og endringer i en komponent vil påvirke alle andre komponenter som er koblet til den. Så kodeomforming blir vanskelig, ettersom du trenger å omorganisere alle andre komponenter i den tilkoblede kjeden slik at funksjonaliteten ikke går i stykker. Denne prosessen er tungvint og tar mye kjedelig innsats og tid.

Du bør designe klasser som inneholder færre antall forekomstvariabler, dvs. at klassedesignet ditt er "bra" hvis det inneholder et lite antall forekomstvariabler. Ideelt sett bør hver av metodene i klassen din manipulere en eller flere av disse forekomstvariablene. Teoretisk sett er en klasse maksimalt sammenhengende hvis hver av forekomstvariablene i klassen brukes eller manipuleres av hver av metodene i den klassen. Når samholdet i klassen er høyt, er metodene og datamedlemmene i klassen avhengige av hverandre og fungerer sammen som en enkelt logisk enhet. Imidlertid er det i realiteten ikke mulig å designe slike klasser, eller jeg vil heller si at det ikke er tilrådelig å designe klasser som er maksimalt sammenhengende.

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