Розьніца паміж вэрсіямі «Спадкаваньне (праграмаваньне)»

д
артаграфія
д (Removing Link GA template (handled by wikidata))
д (артаграфія)
У [[аб'ектнааб’ектна-арыентаванае праграмаваньне|аб’ектна-арыентаваным праграмаваньні]] '''спадкаваньне''' — гэта спосаб стварэньня новых [[Кляса (праграмаваньне)|клясаў]] (экзэмпляры якой называюцца [[аб'ект (праграмаваньне)|аб’ектамі]]) выкарыстоўваючы ўжо існуючыя клясы. Новыя клясы, вядомыя як '''вытворныя клясы''', пераймаюць (або '''спадкуюць''') атрыбуты і паводзіны ўжо існуючых клясаў, якія завуцца '''базавымі клясамі''' (альбо клясамі-папярэднікамі). Адной з ідэяў такога мэханізма зьяўляецца паўторнае выкарыстаньне існуючага коду шляхам нязначных зьменаў альбо бязь іх.
 
'''Спадкаваньне''' часам называюць таксама '''абагульненьнем''', таму што гіерархіягерархія паміж клясамі і аб’ектамі можа быць выяўленая ў адносінах тыпу ''ёсьць''. Напрыклад, «садавіна» — гэта абагульненьне «яблыка», «памаранчаапэльсіна», «манга» і шматлікіх іншых. Садавіна можа разглядацца як абстракцыя яблыка, памаранчаапэльсіна і г. д. Наадварот, улічваючы тое, што яблыкі зьяўляюцца садавінай (то бок, яблык '''ёсьць''' садавінай), яблыкі, натуральна, могуць спадкаваць усе ўласьцівасьці, агульныя для фруктаў, такія як, напрыклад, зьяўляцца кантэйнэрам зь мякаці, які ўтрымлівае насеньне.
 
Перавагай спадкаваньня зьяўляецца тое, што модулі з дастаткова падобнымі інтэрфэйсамі могуць падзяляць вялікую колькасьць агульнага коду, што зьмяншае складанасьць праграмы. Таму спадкаваньне мае яшчэ адно прадстаўленьне, якое называецца [[палімарфізм]]ам. Яно апісвае стан, калі вялікая колькасьць частак коду кантралюецца агульным кіруючым кодам.
* '''Адзінкавасьць''': выкарыстоўваючы простае спадкаваньне, падкляса можа спадкаваць толькі адну бацькоўскую клясу. Працягваючы вышэйзгаданы прыклад, <code>Асоба</code> можа быць альбо <code>Студэнтам</code>, альбо <code>Супрацоўнікам</code>, але не абодвума адразу. Выкарыстаньне [[множнае спадкаваньне|множнага спадкаваньня]] часткова вырашае гэту праблему, бо можна вызначыць клясу <code>СупрацоўнікСтудэнт</code>, якая будзе спадкаваць абедзьве клясы <code>Супрацоўнік</code> і <code>Студэнт</code>. Аднак гэта ўсё роўна дазваляе спадкавацца ад кожнай клясы толькі аднойчы, і таму гэтая схэма ня можа выкарыстоўвацца ў выпадках, калі студэнт мае дзьве працы ці наведвае два ўнівэрсытэты.
 
* '''Статычнасьць''': гіерархіягерархія спадкаваньня аб’екта зафіксаваная і вызначаецца толькі аднойчы, калі выбіраецца тып аб’екта, і ня можа быць зьмененая з часам. Такім чынам спадкаваньне не дазваляе аб’екту тыпу <code>Студэнт</code> стаць аб’ектам тыпу <code>Супрацоўнік</code> з захаваньнем стану сваёй бацькоўскай клясы <code>Асоба</code>.
 
* '''Бачнасьць''': калі кліенцкі код мае доступ да аб’екта, звычайна ён мае доступ да дадзеных усіх ягоных бацькоўскіх клясаў. Нават калі бацькоўская кляса ня была аб’яўленая публічнай, кліент усё яшчэ можа прывесьці аб’ект да тыпу бацькоўскай клясы. Напрыклад, не існуе спосабу прадаставіць пэўнаму мэтаду доступ да сярэдняга балу аб’екту клясы <code>Студэнт</code> без прадастаўленьня гэтаму мэтаду доступу да ўсіх асабістых зьвестак, якія захоўваюцца ў бацькоўскай клясе студэнта <code>Асоба</code>.
 
=== Ролі і спадкаваньне ===
Часам праектаваньне, заснаванае на спадкаваньні, выкарыстоўваецца замест роляў. Роля, напрыклад, '''Студэнт''' — гэта роля '''Асобы''' — апісвае характарыстыкі наяўнага аб’екта, таму што аб’ект узаемадзейнічае зь іншым аб’ектам (напрыклад, асоба ў ролі студэнта мусіць наведваць заняткі). Пэўныя мэтады аб’ектна-арыентаванага праектаваньня не адрозьніваюць такога выкарыстаньня роляў ад звычайных аспэктаў аб’ектаў. Але фармеуцца тэндэнцыя выкарыстоўваць спадкаваньне для мадэляваньня роляў, скажам нехта будзе мець студэнцкую ролю асобы, змадэляваную як падкляса клясы Асоба. Аднак, ні гіерархіягерархія спадкаваньня, ні тыпы аб’ектаў ня могуць зьмяняцца з часам. Таму мадэляваньне роляў як падклясаў можа выклікаць сытуацыю, калі ролі будуць зафіксаваныя на момант свайго стварэньня. Напрыклад, Асоба ня зможа проста зьмяніць сваю ролю з Студэнта на Супрацоўніка, калі зьменяцца абставіны.
 
З пункту погляду мадэляваньня такія абмежаваньні часьцяком непажаданыя, таму што яны выклікаюць штучныя абмежаваньні на будучую пашыральнасьць сыстэмы аб’ектаў, што выкліча складанасьці падчас рэалізацыі будучых зьменаў з-за таго, што патрабуецца абнаўленьне бягучай спраектаванай мадэлі.
159 567

зьменаў