OMADA VÕI OLLA?

Auto ja lennuk on sõidukid, seega on ilmselge, et mõlemad klassid tuleks laiendada nende ühisest baasklassist nimega Sõiduk. See on tüüpiline akadeemiline näide, kuid otsustades nende klasside sidumise üle pärimisrelatsiooniga, peaksime olema teadlikud mõningatest tagajärgedest.

Joonis 1 Pärimussuhte rakendamine.

Sellisel juhul on klassid omavahel tihedalt seotud - see tähendab, et iga klassi käitumise muutmine on võimalik saavutada baasklassi muutmise teel. kood. See võib olla nii eelis kui ka puudus - see sõltub sellest, millist käitumist me ootame. Kui pärimist rakendatakse valel ajal, võib uue funktsiooni lisamisel tekkida rakendamisraskusi, sest see ei sobi loodud klassimudeliga. Me peame valima koodi dubleerimise ja mudeli ümberkorraldamise vahel - ja see võib olla tõesti aeganõudev protsess. Me võime nimetada koodi, mis täidab pärimisrelatsiooni, "avatud-suletud" - see tähendab, et see on avatud laiendustele, kuid suletud muudatuste jaoks. Eeldades, et sõidukiklassis on iga sõiduki üldine, defineeritud mootori operatsioon, siis hetkel, kui me tahaksime lisada meie klassihierarhiasse mootorita sõiduki (nt jalgratta) mudeli, peaksime tegema tõsiseid muudatusi oma klassides.

klass Sõiduk
  def start_mootor
  end

  def stop_mootor
  end
end

class Lennuk < Sõiduk
  def move
    start_mootor
    ...
    stop_gine
  end
end

Koostis

Kui meid huvitab ainult mingi osa olemasoleva klassi käitumisest, on hea alternatiiv pärimisele kompositsiooni kasutamine. Selle asemel, et luua alamklassi, mis pärivad kõik käitumised (need, mida me vajame, ja need, mida me üldse ei vaja), saame isoleerida meile vajalikud funktsioonid ja varustada oma objektid viidetega neile. Sellisel viisil loobume mõttest, et objekt on tüüpi baasobjekt, kasuks väide, et see sisaldab ainult mõned osad selle omadustest.

Joonis 2 Koostise kasutamine

Seda lähenemisviisi järgides saame eraldada mootori töö eest vastutava koodi autonoomsesse klassi nimega Engine ja paigutada viited sellele ainult mootoritega sõidukeid esindavates klassides. Funktsioonide isoleerimine kompositsiooni abil muudab sõidukiklassi struktuuri lihtsamaks ja tugevdab üksikute klasside kapseldamist. Nüüd saavad sõidukid mõjutada mootorit ainult selle avaliku liidese abil, sest neil ei ole enam teavet selle rakendamise kohta. Veelgi enam, see võimaldab kasutada eri tüüpi mootoreid erinevates sõidukites ja isegi võimaldada nende vahetamist programmi töötamise ajal. Loomulikult ei ole kompositsiooni kasutamine veatu - me loome lõdvalt seotud klassikomplekti, mida saab kergesti laiendada ja mis on avatud muutmiseks. Kuid samal ajal on iga klass seotud paljude teiste klassidega ja peab omama teavet nende liideste kohta.

klass Sõiduk
end

klass Mootor
  def start
  end

  def stop
  end
end

class Lennuk < Sõiduk
  def initialize
    @engine = Engine.new
  end

  def move
    @engine.start
    @engine.stop
  end

  def change_engine(new_engine)
    @engine = new_engine
  end
end

Valik

Mõlemal kirjeldatud lähenemisviisil on nii eelised kui ka puudused, nii et kuidas nende vahel valida? Pärimine on spetsialiseerumine, seega on kõige parem neid rakendada ainult probleemide puhul, kus on olemas "is-a" tüüpsuhted - nii et me tegeleme tõelise tüübihierarhiaga. Kuna pärimine seob klassid omavahel tihedalt, siis esiteks peaksime alati kaaluma, kas kasutada kompositsiooni või mitte. Kompositsiooni tuleks rakendada probleemide puhul, kus on olemas "on-a" tüübisuhted - seega klassil on palju osi, kuid see on midagi enamat kui klasside kogum. Lennuk koosneb osadest, kuid üksi on ta midagi enamat - tal on lisavõimeid, näiteks lendamine. Selle näitega edasi minnes võivad üksikud osad esineda erinevates erialavariantides ja siis on hea hetk kasutada pärimist.

Nii pärandamine kui ka kompositsioon on vaid vahendid, mis on programmeerijate käsutuses, seega nõuab õige vahendi valimine konkreetse probleemi jaoks kogemust. Nii et harjutame ja õpime oma vigadest 🙂 .