"Hej, Amigo! Jeg vil gerne fortælle dig om en anden fordel ved OOP. Ser du, programmer ligner mere dyr end bygninger. De er ikke bygget, de er vokset. Udvikling betyder konstante ændringer. I byggeriet kan du have en god plan og følg den til et T. Men i softwareudvikling er det ikke tilfældet."

Ganske ofte kan du ikke gøre noget på den måde, du havde tænkt dig, og du skal omarbejde dit program meget. Og endnu oftere ændrer kundens krav sig.

"Men hvad nu hvis kunden leverede en virkelig detaljeret specifikation?"

"Tag et kig på, hvad der sker over tid. Hvis et produkt lykkes, vil kunden gerne udgive en ny version, og så endnu en og endnu en. Og selvfølgelig skal du lave et par " små ændringer " til det eksisterende produkt. Så softwareudvikling er en lang række ændringer. Kun kadencen adskiller sig. En ny version kan udgives hver uge, en gang om måneden eller hver sjette måned."

Java webinar

"Så hvad konkluderer vi af alt dette?"

"Produktets interne struktur skal vedligeholdes på en måde, der gør det muligt at foretage større (og mindre) ændringer med minimal omarbejdning."

"Hvordan gør du det?"

"Vi har allerede talt om, hvordan et program består af objekter, der interagerer med hinanden. Lad os bruge tykke prikker til at repræsentere alle vores programs objekter på tavlen. Vi tegner pile fra hvert objekt (prik) til alle objekterne (prikker), som den interagerer med."

Lad os nu kombinere objekterne (prikkerne) i grupper. Prikker tilhører samme gruppe, hvis de er meget mere forbundet med hinanden end de andre prikker. Hvis de fleste af en prik pile peger på prikker i dens gruppe, så har vi grupperet objekterne korrekt. Prikker inden for samme gruppe siges at være tæt koblede, mens prikker i forskellige grupper er løst koblede.

Dette kaldes " princippet om løs kobling ". Et program er opdelt i flere dele, ofte lag, hvis logik er stærkt knyttet til deres indre struktur og svagt knyttet til andre lag/dele. Interaktion mellem lag er normalt meget opdelt. Et lag kan kalde et andet lag ved kun at bruge en lille delmængde af dets klasser.

"Det samme 'arbejdsdelingsprincip', men i større skala?"

"Netop. Det giver os mulighed for at omorganisere en afdeling, gøre den mere effektiv og ansætte endnu flere folk, og hvis vi ikke ændrer de tværgående protokoller, så vil alle vores ændringer være lokale. Ingen skal omskoles. Det gør vi" t nødt til at omarbejde hele systemet. Hver afdeling kan optimere sine interne anliggender på denne måde, hvis mekanismerne for afdelingsinteraktion er valgt godt."

"Hvis de er udvalgt godt. Og hvad hvis de ikke er udvalgt godt?"

"Så vil du hurtigt løbe tør for " frirum " til at lave ændringer og skal omarbejde hele systemet. Det sker fra tid til anden. Vi kan ikke spå om fremtiden, men vi kan minimere antallet af gange, vi skal omskrive programmet."

"Okay. Jeg ser fordelen ved at dele programmet sådan op, men hvordan kommer OOP ind i billedet?"

"Når vi vælger, hvordan afdelingerne skal struktureres, og hvordan de vil interagere, anvender vi ' abstraktionsprincippet '. I programmering bruges abstraktion til at bestemme den bedste måde at opdele programmet på, og hvordan delene skal interagere. Dette princip kan også anvendes gentagne gange på de bestanddele, indtil vi har opdelt programmet i individuelle klasser."

"Og at skjule den interne struktur af disse dele og strengt begrænse, hvordan de interagerer med andre dele - det er indkapsling , ikke?"

"Nøjagtigt. Indkapsling og abstraktion er hjørnestenene i OOP. Et godt program skal overholde disse to principper. Senere vil vi tage et kig på andre principper og komme til at forstå deres fordele."

"Gode ting. Jeg kan ikke vente!"