Kokonaisuus on suurempi kuin osiensa summa
-Aristoteles
Tämä sitaatti liitetään Aristoteleelle. Peruslähtökohtana on synergia. Stephen Coveyn bestseller-kirjassa The 7 Habits of Highly Effective People (Erittäin tehokkaiden ihmisten 7 tapaa) hänen kuudes tapansa on synergisoida. Se, mikä pätee organisaatioiden kohdalla, pätee myös tietotekniikassa. Esineen runko on arvokkaampi kuin sen yksilö. Tietojenkäsittelytieteessä käytämme termiä koostumus.
Mitä siis tarkoitamme koostumuksella? ”Kompositio on yksi oliokeskeisen ohjelmoinnin peruskäsitteistä. Se kuvaa luokkaa, joka viittaa yhteen tai useampaan muiden luokkien objektiin instanssimuuttujissa. Näin voidaan mallintaa objektien välinen has-a-yhteys.” Näin Stackify kuvaa sitä täällä. Ajattele sitä orkesterina. Yksi esiintyjä on kiva, mutta kun koko ryhmä on yhdessä, musiikki on rikkaampaa ja syvempää.
Hyödyt
Kunnollisella sommittelulla luodun koodin tärkein hyöty on uudelleenkäyttö. Jos sen suunnittelee oikein, sen pitäisi olla helppo käyttää uudelleen. Jos ei, niin se voi olla melko hankalaa. Sen ohella on intuitiivinen ja siisti API eli sovellusohjelmointirajapinta. Kokeneena Java-ohjelmoijana olen kuullut lukuisten ihmisten valittavan Javan säikeistämis-API:n suunnittelusta. Hyvän suunnittelun pitäisi mahdollistaa jonkin asian muuttaminen sisäisesti eikä muuttaa sitä, miten muut ovat vuorovaikutuksessa sen kanssa.
Esimerkkejä
Luotaan esimerkki, jotta näemme, miltä koostaminen näyttää Javassa.
Tässä meillä on määritelty Rooli-luokka.
Rooli-luokkaa käytetään tässä Työntekijä-luokassa. Koostumuksessa sanottaisiin, että Employee-luokka ”has-a” Role.
Hiding
Asiointirajapintamme esimerkissä HotDogGrinder- ja HotDogGrill-luokat ovat paketti-yksityisiä, eikä niitä voi käyttää ulkopuolelta.
Tässä on sovellusrajapintamme julkiset kasvot, HotDogMachine. Tässä luokassa on viittaus kahteen sisäiseen luokkaan, jotka piilotamme API-suunnittelumme avulla.
Kompositio vs. periytyminen
Kehittäjät voivat sekoittaa komposition ja periytymisen. Kuten Steven Lowe huomauttaa tässä ThoughtWorksin blogikirjoituksessa, meidän on valittava tarkkaan, kumpaa käytämme.
Hän jakaa usein kuullun nyrkkisäännön: ”suosi kokoonpanoa periytymisen sijaan”. Kuten minkä tahansa nyrkkisäännön kohdalla, meidän on ymmärrettävä, että ne eivät aina päde. Selvitetään siis muutama asia ennen kuin mennään pidemmälle.
Määritelläänpä periytyminen, koska olemme jo puhuneet sommittelusta pitkään. Perinnöllisyys on yksi oliokeskeisen ohjelmoinnin perusta. Jos meillä on esimerkiksi ruoka-luokka, niin leipä-luokka periytyy ruoka-luokasta. Kun taas kompositio käsittelee elementtejä, jotka ovat osa suurempaa kokonaisuutta.
Lowe muistuttaa meitä siitä, että kun voisimme käyttää jompaakumpaa, meidän on esitettävä kaksi eri kysymystä. Ensimmäinen: ”Toimialasi käsitteiden esittäminen/toteuttaminen on yksi ulottuvuus”. Pohjimmiltaan, jos molemmat ovat samalla toimialueella, periytyminen on luultavasti paras vaihtoehto. Toiseksi: ”Toimialasi käsitteiden semantiikka ja niiden suhde toisiinsa on toinen ulottuvuus.” Luomasi komponentit alkavat välittää toiselle tämä voisi olla merkki siitä, että sinun pitäisi ehkä harkita uudelleen periytymisen käyttöä sen sijaan.”
Kompositio on ohjelmistokehityksen suuri periaate, jonka monet meistä ammattilaisista sotkevat. Olen tehnyt tämän itsekin, kun olen luonut ratkaisuja lähestymättä sitä oikein. Nopea valkotaulukeskustelu kollegan kanssa tai jonkin asian hahmottaminen paperille voi auttaa sinua ymmärtämään, milloin kahden objektin välillä on ”has-a”-suhde. Kun olet lukenut tämän läpi, sinun pitäisi myös ymmärtää sen hyödyt ja osata käyttää sitä esimerkissä. Yritä rakentaa joitakin esimerkkejä ja käytä sitä, niin sinun pitäisi tietää, oletko oikealla tiellä vai olisiko periytyminen kenties parempi tie.
Katso lisää loistavaa sisältöä ja tilaa osoitteessa MyITCareerCoach.com
