Pamana bilang isang phenomenon

Upang sabihin sa iyo ang katotohanan, hindi ko unang pinlano ang artikulong ito. Itinuring ko na ang mga isyu na gusto kong talakayin dito ay walang halaga, hindi man lang dapat banggitin. Gayunpaman, sa proseso ng pagsulat ng mga artikulo para sa site na ito, itinaas ko ang isang talakayan ng maramihang pamana sa isa sa mga forum. Bilang isang resulta, ito ay naka-out na ang karamihan sa mga developer ay may isang napaka-malabo na pag-unawa sa mana. At, ayon dito, marami siyang pagkakamali. Dahil ang mana ay isa sa pinakamahalagang katangian ng OOP (kung hindi man ang pinakamahalaga!), Nagpasya akong maglaan ng hiwalay na artikulo sa hindi pangkaraniwang bagay na ito. * * * Una, gusto kong makilala ang dalawang konsepto - bagay at klase. Ang mga konseptong ito ay patuloy na nalilito. Samantala, sila ang sentro ng OOP. At, sa palagay ko, kailangang malaman ang mga pagkakaiba sa pagitan nila. Kaya, ang bagay. Talaga, ito ay kahit ano. Narito ang kubo. Kahoy, asul. Ang haba ng gilid ay 5 cm. Ito ay isang bagay. At mayroong isang pyramid. Plastic, pula. 10 cm tadyang. Ito rin ay isang bagay. Ano ang pagkakatulad nila? Iba't ibang laki. Iba't ibang hugis. Iba't ibang materyal. Gayunpaman, mayroon silang pagkakatulad. Una sa lahat, ang kubo at ang pyramid ay regular na polyhedra. Yung. ang kabuuan ng bilang ng mga vertices at ang bilang ng mga mukha ay 2 higit pa kaysa sa bilang ng mga gilid. Dagdag pa. Ang parehong mga hugis ay may mga mukha, mga gilid at mga vertice. Ang parehong mga figure ay may tulad na katangian bilang laki ng tadyang. Ang parehong mga hugis ay maaaring paikutin. Ang parehong mga figure ay maaaring iguguhit. Ang huling dalawang katangian ay pag-uugali na. At iba pa. Ipinapakita ng kasanayan sa programming na mas madaling gumana sa mga homogenous na bagay kaysa sa mga heterogenous. At dahil mayroon pa ring pagkakatulad sa pagitan ng mga figure na ito, may pagnanais na kahit papaano ay i-highlight ang pagkakatulad na ito. Dito pumapasok ang konsepto ng klase. Kaya, ang kahulugan.

Ang isang klase ay isang deskriptor ng mga karaniwang katangian ng isang pangkat ng mga bagay. Ang mga katangiang ito ay maaaring parehong katangian ng mga bagay (laki, timbang, kulay, atbp.), at mga pag-uugali, tungkulin, atbp.

Magkomento. Ang salitang "lahat" (descriptor ng lahat ng pag-aari) ay hindi binibigkas. Na nangangahulugan na ang anumang bagay ay maaaring kabilang sa maraming iba't ibang klase. Kunin natin ang parehong halimbawa na may mga geometric na hugis bilang batayan. Ang pinaka-pangkalahatang paglalarawan ay regular polyhedron . Anuman ang laki ng gilid, bilang ng mga mukha at mga vertex. Ang tanging alam natin ay ang figure na ito ay may mga vertices, gilid at mukha, at ang mga haba ng mga gilid ay pantay. Dagdag pa. Maaari naming gawing mas tiyak ang paglalarawan. Sabihin nating gusto nating iguhit ang polyhedron na ito . Ipakilala natin ang gayong konsepto bilang isang iginuhit na regular na polyhedron . Ano ang kailangan natin para sa pagguhit? Paglalarawan ng isang pangkalahatang paraan ng pagguhit na hindi nakadepende sa mga partikular na vertex coordinates. Marahil ang kulay ng bagay. Ngayon ipakilala natin ang mga klase Cube at Tetrahedron . Ang mga bagay na kabilang sa mga klaseng ito ay tiyak na regular na polyhedra. Ang pagkakaiba lang ay mahigpit na naayos na ang bilang ng mga vertex, gilid at mukha para sa bawat isa sa mga bagong klase. Dagdag pa, alam ang uri ng isang tiyak na pigura, maaari kaming magbigay ng isang paglalarawan ng paraan ng pagguhit. Nangangahulugan ito na ang anumang bagay ng mga klase ng Cube o Tetrahedron ay isa ring bagay ng iginuhit na regular na klase ng polyhedron . Mayroong hierarchy ng mga klase. Sa hierarchy na ito bumaba tayo mula sa pinakapangkalahatang paglalarawan hanggang sa pinakaespesipiko. Tandaan na ang isang bagay ng anumang klase ay umaangkop din sa paglalarawan ng anumang mas pangkalahatang klase sa hierarchy. Ang ugnayang ito ng klase ay tinatawag na mana . Ang bawat klase ng bata ay nagmamana ng lahat ng mga katangian ng magulang, mas pangkalahatan, at (maaaring) nagdaragdag ng ilan sa sarili nito sa mga katangiang ito. O kaya naman, na-override nito ang ilang katangian ng parent class. Dito gusto kong mag-quote mula sa klasikong libro ni Gradi Bucha sa object-oriented na disenyo:

Ang inheritance, samakatuwid, ay tumutukoy sa isang "ay isang" hierarchy sa mga klase, kung saan ang subclass ay namamana mula sa isa o higit pang mga superclass. Ito ay sa katunayan ang litmus test para sa mana. Dahil sa mga klase A at B, kung ang A "ay hindi" uri ng B, kung gayon ang A ay hindi dapat maging isang subclass ng B.

Isinalin, parang ganito:

Sa gayon, tinutukoy ng inheritance ang isang "ay" hierarchy sa pagitan ng mga klase, kung saan ang isang subclass ay namamana mula sa isa o higit pang mga superclass. Ito ay, sa katunayan, ang pagtukoy sa pagsubok (sa literal, isang litmus test, ang aking tala) para sa mana. Kung mayroon tayong mga klase A at B, at kung ang klase A ay "hindi" isang variant ng klase B, kung gayon ang A ay hindi dapat isang subclass ng B.

Ang mga nakabasa na hanggang dito ay malamang na iikot ang kanilang daliri sa kanilang templo sa pagkataranta. Ang unang naisip ay na ito ay walang kuwenta! Ito ay totoo. Ngunit kung alam mo kung gaano karaming nakatutuwang mga hierarchy ng mana ang nakita ko! Sa diskusyon na iyon na binanggit ko sa simula, ang isa sa mga kalahok ay medyo seryosong nagmana ng tangke mula sa... isang machine gun!!! Sa simpleng dahilan na MAY machine gun ang tangke. At ito ang pinakakaraniwang pagkakamali. Ang pagmamana ay nalilito sa pagsasama-sama - ang pagsasama ng isang bagay sa loob ng isa pa. Ang tangke ay hindi isang machine gun, naglalaman ito ng isa. At dahil sa error na ito, kadalasan ay may pagnanais na gumamit ng maramihang mana. Direktang lumipat tayo ngayon sa Java. Ano ang mayroon sa mga tuntunin ng mana? Mayroong dalawang uri ng mga klase sa wika - ang mga may kakayahang maglaman ng isang pagpapatupad, at ang mga hindi magawa ito. Ang huli ay tinatawag na mga interface, bagaman sa esensya ang mga ito ay ganap na abstract na mga klase. Kaya, pinapayagan ka ng wika na magmana ng isang klase mula sa isa pang klase na posibleng naglalaman ng pagpapatupad. PERO MULA SA ISA LANG! Hayaan akong ipaliwanag kung bakit ito ginawa. Ang punto ay ang bawat pagpapatupad ay maaari lamang makitungo sa bahagi nito - sa mga variable at pamamaraan na alam nito. At kahit na minana natin ang klase C mula sa A at B , kung gayon ang pamamaraan processA , minana mula sa klase A, ay maaari lamang gumana sa panloob na variable a , dahil wala itong alam tungkol sa b , tulad ng wala itong alam tungkol sa c at ang pamamaraan processC . Gayundin ang paraan ng prosesoB maaari lamang gumana sa variable b. Iyon ay, sa esensya, ang mga minanang bahagi ay nakahiwalay. Tiyak na maaaring gumana ang Class C sa kanila, ngunit maaari rin itong gumana sa mga bahaging ito kung isasama lang sila bilang bahagi nito sa halip na minana. Gayunpaman, may isa pang istorbo dito, na ang overlap ng mga pangalan. Kung ang mga pamamaraan na processA at processB ay pinangalanang pareho, sabihin ang proseso, kung gayon ano ang epekto ng pagtawag sa paraan ng proseso ng klase C ? Alin sa dalawang pamamaraan ang tatawagin? Siyempre, ang C++ ay may mga kontrol sa sitwasyong ito, ngunit hindi ito nagdaragdag ng pagkakaisa sa wika. Kaya, ang mana ng pagpapatupad ay hindi nagbibigay ng mga pakinabang, ngunit may mga disadvantages. Para sa kadahilanang ito, ang pagpapatupad na mana sa Java ay inabandona. Gayunpaman, ang mga developer ay naiwan ng ganoong opsyon para sa maramihang pamana bilang mana mula sa isang interface. Sa mga tuntunin ng Java, isang pagpapatupad ng interface. Ano ang interface? Isang hanay ng mga pamamaraan. (Kasalukuyang hindi namin isinasaalang-alang ang kahulugan ng mga constant sa mga interface; higit pa tungkol diyan dito .) Ano ang isang paraan? At ang isang pamamaraan, sa kaibuturan nito, ay tumutukoy sa pag-uugali ng isang bagay. Ito ay hindi nagkataon na ang pangalan ng halos bawat paraan ay naglalaman ng isang aksyon - getXXX , drawXXX , countXXX , atbp. At dahil ang isang interface ay isang koleksyon ng mga pamamaraan, ang interface ay, sa katunayan, isang determinant ng pag-uugali . Ang isa pang pagpipilian para sa paggamit ng isang interface ay upang tukuyin ang papel ng isang bagay. Tagamasid, Tagapakinig , atbp. Sa kasong ito, ang pamamaraan ay talagang ang sagisag ng isang reaksyon sa ilang panlabas na kaganapan. Iyon ay, muli, pag-uugali. Siyempre, ang isang bagay ay maaaring magkaroon ng maraming iba't ibang mga pag-uugali. Kung kailangan itong i-render, ito ay i-render. Kung kailangan niyang iligtas, siya ay maliligtas. Well, atbp. Alinsunod dito, ang kakayahang magmana mula sa mga klase na tumutukoy sa pag-uugali ay napaka-kapaki-pakinabang. Gayundin, ang isang bagay ay maaaring magkaroon ng iba't ibang mga tungkulin. Gayunpaman, ang pagpapatupadAng pag-uugali ay ganap na nasa budhi ng klase ng bata. Ang pamana mula sa isang interface (implementasyon nito) ay nagsasabi na ang isang bagay ng klase na ito ay dapat na magawa ito at iyon. At kung PAANO ito ginagawa ay independyenteng tinutukoy ng bawat klase na nagpapatupad ng interface. Bumalik tayo sa mga pagkakamali sa mana. Ang aking karanasan sa pagbuo ng iba't ibang mga sistema ay nagpapakita na ang pagkakaroon ng mana mula sa mga interface, maaari mong ipatupad ang anumang sistema nang hindi gumagamit ng maramihang pagpapatupad na mana. At samakatuwid, kapag nakatagpo ako ng mga reklamo tungkol sa kakulangan ng maramihang mana sa anyo kung saan ito umiiral sa C++, para sa akin ito ay isang siguradong tanda ng hindi tamang disenyo. Ang pinakakaraniwang pagkakamali ay ang nabanggit ko na - ang mana ay nalilito sa pagsasama-sama. Minsan ito ay nangyayari dahil sa mga maling pagpapalagay. Yung. Kunin, halimbawa, ang isang speedometer, pinagtatalunan na ang bilis ay masusukat lamang sa pamamagitan ng pagsukat ng distansya at oras, pagkatapos kung saan ang speedometer ay matagumpay na minana mula sa ruler at sa orasan, kaya nagiging ruler at ang orasan, ayon sa kahulugan ng mana. (Ang aking mga kahilingan na sukatin ang oras gamit ang isang speedometer ay kadalasang sinasagot ng mga biro. O hindi sila sumasagot.) Ano ang pagkakamali dito? Sa premise. Ang katotohanan ay hindi sinusukat ng speedometer ang oras. At mga distansya, sa pamamagitan ng paraan, masyadong. Ang odometer, na matatagpuan sa anumang speedometer, ay isang klasikong halimbawa ng pangalawang aparato sa parehong pabahay, i.e. pagsasama-sama. Hindi kinakailangan upang sukatin ang bilis. Maaari itong alisin nang buo - hindi ito makakaapekto sa pagsukat ng bilis sa anumang paraan. Minsan ang gayong mga pagkakamali ay sinasadya. Ito ay mas masahol pa. "Oo, alam kong mali ito, ngunit mas maginhawa para sa akin." Ano ang maaaring humantong sa? Ngunit narito kung ano: magmamana tayo ng tangke mula sa isang kanyon at isang machine gun. Ito ay mas maginhawa sa ganitong paraan. Bilang resulta, ang tangke ay nagiging isang kanyon at isang machine gun. Susunod ay bibigyan natin ang eroplano ng dalawang machine gun at isang kanyon. Ano ang makukuha natin? Isang sasakyang panghimpapawid na may nasuspinde na mga armas sa anyo ng tatlong tangke! Dahil TIYAK na may isang tao na, nang hindi maintindihan, ay gumagamit ng tangke bilang machine gun. Eksklusibo ayon sa hierarchy ng mana. At siya ay magiging ganap na tama, dahil ang isa na nagdisenyo ng gayong hierarchy ay nagkamali.

Sa pangkalahatan, hindi ko talaga naiintindihan ang diskarteng " ito ay mas maginhawa para sa akin sa ganitong paraan". Maginhawang magsulat tulad ng isang tagapakinig, at ang mga nagsasabing basic grammar ay kazly. Nagmamalaki ako, siyempre, ngunit ang pangunahing ideya ay nananatili - bilang karagdagan sa panandaliang kaginhawahan, mayroong isang bagay tulad ng karunungang bumasa't sumulat. Ang konseptong ito ay tinukoy batay sa napakalaking bilang ng karanasan ng mga tao. Sa katunayan, ito ang tinatawag sa Ingles na "pinakamahusay na kasanayan" - ang pinakamahusay na solusyon. At mas madalas kaysa sa hindi, ang mga solusyon na tila mas simple ay nagdudulot ng maraming problema sa hinaharap.

Ang halimbawang ito, siyempre, ay labis na pinalaki at samakatuwid ay walang katotohanan. Gayunpaman, may mga hindi gaanong halatang mga kaso na gayunpaman ay humantong sa mga sakuna na kahihinatnan. Sa pamamagitan ng pagmamana mula sa isang bagay, sa halip na pagsama-samahin ito, binibigyan ng developer ang sinuman ng kakayahang direktang gamitin ang functionality ng magulang na bagay. Sa lahat ng ipinahihiwatig nito. Isipin na mayroon kang isang klase na gumagana sa isang database, DBManager . Lumilikha ka ng isa pang klase na gagana sa iyong data gamit ang DBManager - DataManager . Ang klase na ito ay magsasagawa ng kontrol ng data, pagbabago, karagdagang pagkilos, atbp. Sa pangkalahatan, isang layer sa pagitan ng business layer at ng base layer. Kung nagmamana ka ng DataManager mula sa DBManager, ang sinumang gumagamit nito ay direktang magkakaroon ng access sa database. At, samakatuwid, magagawa niya ang anumang mga aksyon na lumalampas sa kontrol, mga pagbabagong-anyo, atbp. Okay, ipagpalagay natin na walang gustong magdulot ng sinasadyang pinsala at ang mga direktang aksyon ay magiging may kakayahan. Ngunit! Ipagpalagay natin na ang base ay nagbago. Ibig kong sabihin, nagbago ang ilang prinsipyo ng kontrol o pagbabago. Ang DataManager ay binago. Ngunit ang code na dating gumana nang direkta sa database ay patuloy na gagana. Malamang na hindi nila siya maaalala. Ang resulta ay isang error ng ganoong klase na ang mga naghahanap nito ay magiging kulay abo. Hindi kailanman mangyayari sa sinuman na nagtatrabaho sila sa database na lumalampas sa DataManager. Sa pamamagitan ng paraan, isang halimbawa mula sa totoong buhay. Napakatagal bago mahanap ang error. Sa wakas, sasabihin ko ulit. Dapat LAMANG gamitin ang mana kapag may relasyong "ay". Dahil ito ang pinakabuod ng mana - ang kakayahang gumamit ng mga bagay ng isang klase ng bata bilang mga bagay ng isang batayang klase. Kung walang "is" na relasyon sa pagitan ng mga klase, HINDI DAPAT magkaroon ng mana!!! Hindi kailanman at sa anumang pagkakataon. At higit pa - dahil ito ay napaka-kombenyente. Link sa orihinal na pinagmulan: http://www.skipy.ru/philosophy/inheritance.html