Avainsana: liskov substitution principle

SOLID-periatteet

OLYMPUS DIGITAL CAMERAOhjelmiston suunnittelemiseen löytyy useita arkkitehtuuriperiaatteita. Esittelen tässä lyhyesti SOLID-periaatteet. Ne vastaavat olio-ohjelmoinnin haasteisiin.

Ohjelmointiperiaatteet tulevat ajankohtaisiksi, kun samaan sovellukseen kirjoittaa vähän enemmän koodia tai koodia kirjoittaa useampi henkilö. Ymmärrettävyyden ja perusvirheiden välttämiseksi apuun kiiruhtavat arkkitehtuuriperiaatteet. Sehän on hassu sanahirviö.

SOLID-periaatteet tulevat usein vastaan luokkia kirjoittaessa. Avaan lyhyesti nuo viisi periaatetta. Wikipediasta voi lukea ensihätään kattavamman selostuksen ja sieltä löytyvät alkuperäiset lähteet, jos haluat uppoutua syvemmälle.

  • S, Single responsibility principle, muistuttaa yhden luokan vastaavan vain yhdestä asiasta. Esimerkiksi yksi luokka vastaa tiedon järjestämisestä oikeaan järjestykseen. Jos siihen livahtaa toinen vastuu, kuten erilaisen tiedon vertailu tai tiedon lähettäminen rajapinnan läpi, niin jokaista vastuualuetta varten kirjoitetaan erillinen luokka.
  • O, Open/closed principle, avoimen / suljetun luokan periaate. Luokan pitää olla avoin toimintojen ja ominaisuuksien laajentamiselle. Riippuen periaatteen tulkitsemisesta, periaate on aikanaan tarkoittanut abstrakin perusluokan perimistä toteuttavalle luokalle. Peritty luokka voi aina lisätä metodeja ja propertyjä ja siten olla vanhempana toimiva luokka on avoin laajentamiselle. Toisaalta vanhempana toimiva luokka on suljettu, koska sitä ei voi muuttaa.Myöhemmin samaa periaate haluttiin rajata toimimaan rajapintojen, eikä perinnän kautta. Hyvin määritellyt rajapinnat ovat suljettuja, mutta luokan toimintaa voi laajentaa uusilla toiminnoilla tai lisäämällä siihen toisen rajapinnan.
  • L, Liskov substitution principle (LSP), Liskovin korvattavuuden periaate määrittelee, että samaa alatyyppiä olevat oliot voivat korvata toisensa toteuttavassa koodissa. Perintähierarkiaa ajatellen tämä on nykyään itsestään selvää. Jos tytöt ja pojat ovat molemmat lapsia, niin lapsi-olioita sisältävät lista voi sisältää kumman molemman tyyppisiä olioita. Siis poika-olion voi korvata tyttö-oliolla, kun halutaan käyttää oliota lapsi-luokan kautta.
  • I, Interface segregation principle, rajapintojen hajoittamisperiaate kertoo, että yhden yleisen rajapinnan sijaan kannattaa luoda useita hyvin määriteltyjä rajapintoja. Näin ollen luokka tulee sisältämään vain metodeja, joita se käyttää, kun se voi toteuttaa hyvin määritellyn rajapinnan. Yleiset rajapinnat sisältävät turhia metodeja.
  • D, Dependency inversion principle, riippuvuuden kääntämisen periaate kutkuttelee olioiden perimistä. Vanhempana toimivan luokan ei pitäisi riippua lapsiluokkien toteutuksesta, vaan rajapinnoista. Abstraktioiden ei pitäisi riippua yksityiskohdista. Yksityiskohtien pitäisi riippua abstraktioista.Käytännössä suoran perimisen sijaan luokka sisältää propertyjä, joiden tyyppi on rajapinta. Esimerkiksi lapset-lista on kokoelma olioista, jotka toteuttavat ILapsi-rajapinnan. Tyttö ja Poika -oliot eivät peri suoraan lapsi-luokkaa, vaan ne toteuttavat ILapsi-rajapinnan.

Ihania periaatteita.

Miksi? Luettavan, ylläpidettävän ja testattavan koodin kirjoittamiseksi. Koodi on luettavampaa, kun koodin rakenne tulee samojen periaatteiden kautta. Ylläpidettävyys helpottuu, kun luokkien keskenäinen riippuvuus vähenee. Rajapinnat taas auttavat testattavan koodin kirjoittamista.

Riippumatta siitä, haluatko kirjoittaa testejä tai et, niin SOLID helpottaa kehittäjän elämää. Ennen kaikkea muiden kehittäjien elämää. Koodi kirjoitetaan muita kehittäjiä varten, kääntäjä osaa pyöräyttää siitä ohjelman koodin ulkoasusta riippumatta.

Mainokset