Kokonaisuus on suurempi kuin osiensa summa
-Aristoteles
Tämä sitaatti on Aristoteleelle omistettu. 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ä sommittelu.
Sommittelu
Mitä siis tarkoitamme sommittelulla? ”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 sallia jonkin asian muuttaminen sisäisesti eikä muuttaa sitä, miten muut ovat vuorovaikutuksessa sen kanssa.
Esimerkkejä
Luotaanpa esimerkki, jotta näemme, miltä kompositio näyttää Javassa.
Tässä meillä on Role-luokkamme määriteltynä.
Role-luokkaa käytetään tässä Employee-luokassa. Kompositiossa sanoisit, että Employee-luokka ”has-a” Role.
Hiding
Asiointirajapintaesimerkissämme HotDogGrinder- ja HotDogGrill-luokat ovat package-private-luokkia, eikä niihin pääse käsiksi ulkopuolelta.
Tässä on sovellusrajapintaesimerkkimme julkinen puoli, 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 koostumuksesta 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 isompaa kokonaisuutta.
Lowe muistuttaa, että kun voisi 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 samassa toimialueessa 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ämistä 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 jokin esimerkki ja käytä sitä, niin sinun pitäisi tietää, oletko oikealla tiellä vai olisiko periytyminen kenties parempi tie.