Kobling og samhørighed er ofte misforstået i softwareteknik. Dette er udtryk, der bruges til at indikere den kvalitative analyse af modulet i et system, og de hjælper os med at identificere og måle designkompleksiteten af objektorienterede systemer.
Imidlertid er et godt kendskab til begge dele nødvendigt for at opbygge systemer, der er skalerbare, håndterbare og kan udvides over tid. I dette indlæg vil jeg diskutere begge disse; Jeg præsenterer kodeeksempler i mine fremtidige indlæg om dette emne.
Hvordan adskiller samhørighed og kobling sig? Hvordan er begreber samhørighed og kobling relateret til gode eller dårlige softwaredesign? Inden vi udforsker samhørighed og kobling, og hvordan de påvirker softwaredesign, lad os forstå, hvad hvert af disse begreber er og deres typer.
Kobling
Kobling kan defineres som graden af indbyrdes afhængighed mellem softwaremoduler og hvor tæt de er forbundet med hinanden. I det væsentlige angiver kobling styrken af sammenkobling mellem softwaremoduler. Når denne kobling er høj, kan vi antage, at softwaremodulerne er indbyrdes afhængige, dvs. de kan ikke fungere uden den anden. Der er flere dimensioner af kobling:
- Indholdskobling - dette er en type kobling, hvor et bestemt modul kan få adgang til eller ændre indholdet af ethvert andet modul. I det væsentlige, når en komponent overfører parametre til at kontrollere aktiviteten af en anden komponent, er der en kontrolkobling blandt de to komponenter.
- Fælles kobling - dette er en type kobling, hvor du har flere moduler, der har adgang til en delt global data
- Stempelkobling - dette er en type kobling, hvor datastrukturen bruges til at overføre information fra en komponent i systemet til en anden
- Kontrolkobling - dette er en type kobling, hvor et modul kan ændre strømmen af udførelse af et andet modul
- Datakobling - i denne type kobling interagerer to moduler ved at udveksle eller videregive data som en parameter
Samhørighed
Samhørighed angiver niveauet for intraafhængighed blandt elementerne i et softwaremodul. Med andre ord er samhørighed et mål for, i hvilken grad ansvarsområderne for et enkelt modul eller en komponent danner en meningsfuld enhed. Samhørighed er af følgende typer:
- Co-tilfældig samhørighed - dette er en ikke-planlagt tilfældig samhørighed, der kan være et resultat af opdeling af et modul i mindre moduler.
- Logisk samhørighed - dette er en type samhørighed, hvor flere logisk relaterede funktioner eller dataelementer placeres i den samme komponent
- Temporal samhørighed - dette er en type samhørighed, hvor elementer i et modul er grupperet på en måde, hvor de behandles på samme tidspunkt. Et eksempel kan være en komponent, der bruges til at initialisere et sæt objekter.
- Procedurel samhørighed - dette er en type samhørighed, hvor funktionerne i en komponent er grupperet på en måde, så de kan udføres sekventielt og gøre dem proceduremæssigt sammenhængende
- Kommunikativ samhørighed - i denne type samhørighed er elementerne i et modul logisk grupperet på en måde, som de udfører sekventielt, og de arbejder på de samme data
- Sekventiel samhørighed - i denne type samhørighed er elementerne i et modul grupperet på en sådan måde, at output fra en af dem bliver input til den næste - de udføres alle sekventielt. I det væsentlige, hvis output fra en del af en komponent er input fra en anden, siger vi, at komponenten har sekventiel samhørighed.
- Funktionel samhørighed - dette er den bedste og mest foretrukne type samhørighed, hvor samhørighedsgraden er den højeste. I denne type samhørighed grupperes elementerne i et modul funktionelt i en logisk enhed, og de arbejder sammen som en logisk enhed - dette fremmer også fleksibilitet og genanvendelighed.
De bedste fremgangsmåder
Stram kobling øger vedligeholdelsesomkostningerne, da det er vanskeligt, og ændringer af en komponent vil påvirke alle andre komponenter, der er tilsluttet den. Så kodeomdannelse bliver vanskelig, da du bliver nødt til at omformulere alle andre komponenter i den tilsluttede kæde, så funktionaliteten ikke bryder. Denne proces er besværlig og tager meget kedelig indsats og tid.
Du skal designe klasser, der indeholder det færre antal forekomstvariabler, dvs. dit klassedesign er "godt", hvis det indeholder et lille antal forekomstvariabler. Ideelt set bør hver af metoderne i din klasse manipulere en eller flere af disse instansvariabler. Teoretisk er en klasse maksimalt sammenhængende, hvis hver af instansvariablerne i klassen bruges eller manipuleres af hver af metoderne i denne klasse. Når samhørigheden i klassen er høj, er metoderne og datamedlemmerne i klassen afhængige af hinanden og arbejder sammen som en enkelt logisk enhed. Men i virkeligheden er det ikke muligt at designe sådanne klasser, eller jeg vil hellere sige, det anbefales ikke at designe klasser, der er maksimalt sammenhængende.
