Barbara Liskovin korvausperiaate
Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 29. maaliskuuta 2022 tarkistetusta versiosta . tarkastukset vaativat 4 muokkausta .Liskovin substituutioperiaate ( LSP ) olioohjelmoinnissa on erityinen alatyypin määritelmä , jonka Barbara Liskov ehdotti vuonna 1987 konferenssissa, jonka otsikko oli Data Abstraction and Hierarchy [1] .
Myöhemmässä artikkelissa [2] Liskov muotoili lyhyesti periaatteensa seuraavasti:
Antaa olla ominaisuus, joka pätee jonkin tyyppisille objekteille . Silloin sen on oltava tosi myös objekteille , joiden tyyppi on jossa on tyypin alatyyppi .
Robert S. Martin määritteli [3] tämän periaatteen seuraavasti:
Perustyyppiä käyttävien funktioiden on kyettävä käyttämään perustyypin alatyyppejä tietämättään.Siten Liskovin ajatus "alatyypistä" määrittelee substituution käsitteen - jos S on T:n alatyyppi, niin T-tyypin objektit ohjelmassa voidaan korvata S-tyypin objekteilla ilman, että ohjelman halutut ominaisuudet muuttuvat ( esim. oikeellisuus ).
Tämä periaate on tärkein kriteeri arvioitaessa tehtyjen päätösten laatua perintöhierarkioita rakennettaessa. Se voidaan muotoilla yksinkertaisena sääntönä: tyyppi S on T:n alatyyppi, jos ja vain jos jokainen tyypin S objekti oS vastaa jotakin tyypin T objektia oT siten, että kaikille T:n suhteen toteutetuille ohjelmille P P:n käyttäytyminen ei muutu, jos oT korvataan oS:llä.
Yksinkertaisemmin sanottuna voidaan sanoa, että perivien luokkien käyttäytymisen ei pitäisi olla ristiriidassa perusluokan määrittämän käyttäytymisen kanssa, eli perivien luokkien käyttäytymistä tulisi odottaa perustyyppimuuttujaa käyttävälle koodille.
Sutter ja Alexandrescu käyttävät C++:n käyttöoppaassaan myös ilmaisua "alaluokka ei saa vaatia soittajalta enempää kuin perusluokka, eikä antaa soittajalle perusluokkaa vähemmän" tämän periaatteen ilmaisemiseksi. Näiden kirjoittajien mukaan julkista perintöä C++:ssa voidaan käyttää vain, jos se täyttää Liskovin periaatteen. Yksityistä perintöä heidän mielestään sallitaan käyttää tukikohdan suojattuun osaan ja ohittaa virtuaaliset menetelmät . Missään muussa tapauksessa, eli vain peruskoodin uudelleenkäyttöön, perintöä ei voida käyttää.
Syyt: Julkisen perinnön käyttö koodin uudelleenkäyttöön saa ulkomaailman pitämään Derived-luokkaa perusluokan muunnelmana, ja saattaa olla koodia, joka käyttää tätä tosiasiaa eksplisiittisesti hyväkseen. Tämä rajoittaa suuresti arkkitehdin mahdollisuuksia ylläpitää ja muokata Derived-luokkaa edelleen.
Sopimussuunnittelu
Liskovin korvausperiaate liittyy läheisesti sopimusohjelmointimetodologiaan ja johtaa joihinkin rajoituksiin siihen, miten sopimukset voivat olla vuorovaikutuksessa perinnön kanssa :
- Edellytyksiä ei voi vahvistaa alaluokassa.
- Jälkiehtoja ei voi lieventää alaluokassa.
- Historialliset rajoitukset ("historiasääntö") - alaluokka ei saa luoda uusia perusluokan ominaisuuksien mutaattoreita. Jos perusluokka ei tarjonnut menetelmiä siinä määriteltyjen ominaisuuksien muokkaamiseen, ei myöskään kyseisen luokan alatyyppi saa luoda sellaisia menetelmiä. Toisin sanoen perusluokan muuttumaton data ei saa olla muuttuvaa alaluokassa. Tämä Liskovin ja Wingin esittämä konsepti oli innovatiivinen ohjelmistoarkkitehtuurin teorialle.
Lisäksi LSP-periaate tarkoittaa, että alaluokkamenetelmät eivät voi heittää muita ylimääräisiä poikkeuksia kuin ne, jotka ovat itse superluokkamenetelmien heittämien poikkeusten alaluokkia. Katso kovarianssi ja kontravarianssi sekä tietotyypit .
Funktio, joka käyttää Liskov-periaatteen vastaista luokkahierarkiaa, sen lisäksi, että se toimii viittauksella perusluokkaan, on pakotettu tietämään myös alaluokasta. Tällainen funktio rikkoo avoin/kiinni -periaatetta , koska se vaatii muokkauksen, jos järjestelmään tulee uusia johdettuja luokkia.
Tässä yhteydessä korvausperiaate voidaan muotoilla uudelleen seuraavasti:
Funktioiden, jotka käyttävät viittauksia perusluokkiin, pitäisi pystyä käyttämään johdettujen luokkien objekteja tietämättään.Barbara Liskovin periaate saa meidät ajattelemaan, mitä "tyyppiilmoitus" tarkoittaa käyttämämme olio-ohjelmointikielen kannalta. Riittääkö, että kuvaamme objektin rajapinnan käyttämällä tavallista abstraktia luokkaa, jossa on lista menetelmistä, parametrityypeistä ja palautusarvo? Kuinka voimme ilmoittaa vaatimukset menetelmän parametrien ja ominaisuuksien arvoille, jotka palautusarvolla on? Kuinka kuvaamme poikkeuksia, jotka menetelmä voi heittää suorituksen aikana? Miten voidaan kuvata kohteen tilan muutosta sen elinkaaren eri vaiheissa?
Kysymällä itseltäsi nämä kysymykset ja etsimällä vastauksia, voit suunnitella järjestelmän, joka todellakin täyttää Barbara Liskovin korvausperiaatteen.
Katso myös
- KIINTEÄ - kirjain "L " lyhenteessä tarkoittaa Barbara Liskovin korvausperiaatetta
- Kovarianssi ja kontravarianssi (ohjelmointi)
Muistiinpanot
- ↑ Liskov, Barbara Datan abstraktio ja hierarkia (4. lokakuuta 1987). Haettu 23. maaliskuuta 2008. Arkistoitu alkuperäisestä 30. kesäkuuta 2019.
- ↑ Liskov, Barbara ; Siipi, Jeanette . Behavioral Subtyping käyttäen invariantteja ja rajoituksia ( PS ) (heinäkuu 1999). Haettu 5. lokakuuta 2006. Arkistoitu alkuperäisestä 30. elokuuta 2012.
- ↑ Martin, Robert Liskov-korvausperiaate ( PS ). Haettu 5. lokakuuta 2006. Arkistoitu alkuperäisestä 30. elokuuta 2012.