"Hei, Amigo! Jeg vil gjerne fortelle deg om en annen fordel med OOP. Du skjønner, programmer er mer som dyr enn bygninger. De er ikke bygget, de er vokst. Utvikling betyr konstante endringer. I konstruksjon kan du ha en god plan og følg den til en T. Men i programvareutvikling er det ikke tilfelle."
Ganske ofte kan du ikke gjøre noe på den måten du hadde tenkt, og du må omarbeide programmet mye. Og enda oftere endres kundens krav.
"Men hva om kunden ga en virkelig detaljert spesifikasjon?"
"Ta en titt på hva som skjer over tid. Hvis et produkt lykkes, vil kunden ønske å gi ut en ny versjon, og deretter en til, og en til. Og, selvfølgelig, må du gjøre noen « små endringer » for å det eksisterende produktet. Så programvareutvikling er en lang rekke endringer. Bare takten er forskjellig. En ny versjon kan bli utgitt hver uke, en gang i måneden eller hver sjette måned."
"Så hva konkluderer vi med alt dette?"
"Produktets interne struktur må opprettholdes på en måte som gjør at større (og mindre) endringer kan gjøres med minimum omarbeiding."
"Hvordan gjør du det?"
"Vi har allerede snakket om hvordan et program består av objekter som interagerer med hverandre. La oss bruke tykke prikker for å representere alle programmets objekter på tavlen. Vi tegner piler fra hvert objekt (prikk) til alle objektene (prikker) som den samhandler med."
La oss nå kombinere objektene (prikkene) i grupper. Prikker tilhører samme gruppe hvis de er mye mer knyttet til hverandre enn de andre prikkene. Hvis de fleste av en prikks piler peker mot prikker i gruppen, har vi gruppert objektene riktig. Prikker innenfor samme gruppe sies å være tett koblet, mens prikker i forskjellige grupper er løst koblet.
Dette kalles « prinsippet for løs kobling ». Et program er delt opp i flere deler, ofte lag, hvis logikk er sterkt knyttet til deres indre struktur og svakt knyttet til andre lag/deler. Interaksjon mellom lag er vanligvis svært oppdelt. Ett lag kan kalle et annet lag ved å bruke bare en liten delmengde av klassene.
"Det samme 'arbeidsdelingsprinsippet', men i større skala?"
"Nettopp. Dette gjør at vi kan omorganisere en avdeling, gjøre den mer effektiv og ansette enda flere folk, og hvis vi ikke endrer de interdepartementale protokollene, vil alle endringene våre være lokale. Ingen må omskoleres. Det gjør vi" t må omarbeide hele systemet. Hver avdeling kan optimalisere sine interne forhold på denne måten hvis mekanismene for avdelingssamhandling velges godt."
"Hvis de er godt utvalgt. Og hva hvis de ikke er godt utvalgt?"
«Da vil du raskt gå tom for « slingringsmonn » for å gjøre endringer, og må omarbeide hele systemet. Det skjer fra tid til annen. Vi kan ikke forutsi fremtiden, men vi kan minimere antall ganger vi må omskrive programmet."
"Ok. Jeg ser fordelen med å dele opp programmet slik, men hvordan kommer OOP inn i bildet?"
"Når vi velger hvordan vi skal strukturere avdelingene og hvordan de skal samhandle, bruker vi ' abstraksjonsprinsippet '. I programmering brukes abstraksjon for å bestemme den beste måten å dele opp programmet og hvordan delene skal samhandle. Dette prinsippet kan også brukes gjentatte ganger på bestanddelene til vi har delt opp programmet i individuelle klasser."
"Og å skjule den interne strukturen til disse delene, og strengt begrense hvordan de samhandler med andre deler - det er innkapsling , ikke sant?"
"Akkurat. Innkapsling og abstraksjon er hjørnesteinene i OOP. Et godt program må følge disse to prinsippene. Senere skal vi se på andre prinsipper og forstå deres fordeler."
"Bra greier. Jeg kan ikke vente!"
GO TO FULL VERSION