Ännu en förklaring av OOP (lös koppling, tight cohesion)

"Hej, Amigo! Jag skulle vilja berätta om en annan fördel med OOP. Du förstår, program är mer som djur än byggnader. De är inte byggda, de är odlade. Utveckling innebär ständiga förändringar. I byggandet kan du ha en bra plan och följ den till ett T. Men inom mjukvaruutveckling är det inte så."

Ganska ofta kan du inte göra något på det sätt du tänkt dig, och du måste omarbeta ditt program mycket. Och ännu oftare förändras kundens krav.

"Men tänk om kunden lämnade en riktigt detaljerad specifikation?"

"Ta en titt på vad som händer med tiden. Om en produkt lyckas, kommer kunden att vilja släppa en ny version, och sedan en till, och en till. Och, naturligtvis, måste du göra några " små ändringar " för att den befintliga produkten. Så mjukvaruutveckling är en lång rad förändringar. Endast kadensen skiljer sig. En ny version kan släppas varje vecka, en gång i månaden eller var sjätte månad."

"Så vad drar vi slutsatsen av allt detta?"

"Produktens interna struktur måste bibehållas på ett sätt som gör att större (och mindre) ändringar kan göras med minimal omarbetning."

"Hur gör man det?"

"Vi har redan pratat om hur ett program består av objekt som interagerar med varandra. Låt oss använda tjocka punkter för att representera alla vårt programs objekt på tavlan. Vi kommer att rita pilar från varje objekt (prick) till alla objekten (prickar) som den interagerar med."

Låt oss nu kombinera objekten (prickarna) i grupper. Prickar tillhör samma grupp om de är mycket mer kopplade till varandra än de andra prickarna. Om de flesta av en pricks pilar pekar på punkter i dess grupp, så har vi grupperat objekten korrekt. Prickar inom samma grupp sägs vara tätt kopplade, medan prickar i olika grupper är löst kopplade.

Detta kallas " principen för lös koppling ". Ett program är uppdelat i flera delar, ofta lager, vars logik är starkt knuten till deras inre struktur och svagt knuten till andra lager/delar. Interaktionen mellan skikten är vanligtvis mycket uppdelad. Ett lager kan anropa ett annat lager med bara en liten delmängd av dess klasser.

"Samma "arbetsfördelningsprincip", men i större skala?"

"Precis. Detta gör att vi kan omorganisera en avdelning, göra den mer effektiv och anställa ännu fler personer, och om vi inte ändrar de interdepartementala protokollen kommer alla våra förändringar att vara lokala. Ingen behöver omskolas. Det gör vi" t måste omarbeta hela systemet. Varje avdelning kan optimera sina interna angelägenheter på detta sätt om mekanismerna för avdelningsinteraktion är väl valda."

"Om de är väl valda. Och vad händer om de inte är väl valda?"

"Då kommer du snabbt att få slut på " rörelseutrymme " för att göra ändringar och måste omarbeta hela systemet. Det händer då och då. Vi kan inte förutse framtiden, men vi kan minimera antalet gånger vi måste skriva om programmet."

"Okej. Jag ser fördelen med att dela upp programmet så, men hur kommer OOP in i bilden?"

"När vi väljer hur institutionerna ska struktureras och hur de ska interagera tillämpar vi ' abstraktionsprincipen '. I programmering används abstraktion för att bestämma det bästa sättet att dela upp programmet och hur delarna ska interagera. Denna princip kan också tillämpas upprepade gånger på de ingående delarna tills vi har delat upp programmet i individuella klasser."

"Och att dölja den interna strukturen hos dessa delar och strikt begränsa hur de interagerar med andra delar - det är inkapsling , eller hur?"

"Precis. Inkapsling och abstraktion är hörnstenarna i OOP. Ett bra program måste följa dessa två principer. Senare ska vi ta en titt på andra principer och förstå deras fördelar."

"Bra grejer. Jag kan inte vänta!"