Аб’ектна-арыентаванае праграмаваньне
Аб’е́ктна-арыентава́нае праграмава́ньне — парадыгма праграмаваньня, дзе ў якасьці асноўных элемэнтаў для стварэньня праграмаў выкарыстоўваюцца асобныя «аб’екты», якія ўтрымліваюць дадзеныя і код для іхнай апрацоўкі. У ёй выкарыстоўваюцца тэхналёгіі папярэдніх парадыгмаў, уключаючы спадкаваньне, модульнасьць, палімарфізм і інкапсуляцыю. Нягледзячы на тое, што гэтая парадыгма зьявілася ў 1960-х, яна ня мела шырокага ўжываньня да 1990-х. На сёньняшні дзень існуе вялікая колькасьць моваў праграмаваньня, якія падтрымліваюць гэтую парадыгму.
Разьвіцьцё
рэдагавацьАб’ектна-арыентаванае праграмаваньне сягае сваімі каранямі ў 1960-я — час, на які прыйшоўся крызіс праграмнага забесьпячэньня, які заключаўся ў тым, што ў той час паўстала пытаньне: апаратнае і праграмнае забесьпячэньне робіцца ўсё больш складаным, як пры гэтым можна захаваць якасьць праграмаў? Гэтая праблема разьвязваецца пры дапамозе аб’ектна-арыентаванага праграмаваньня ўвядзеньнем модульнасьці ў праграмнае забесьпячэньне[1].
Першай мовай праграмаваньня, дзе зьявіліся канцэпцыі, на якіх грунтуецца аб’ектна-арыентаванае праграмаваньне (аб’екты, клясы, падклясы, віртуальныя мэтады, сапраграмы, прыбіраньне сьмецьця і мадэляваньне асобных падзеяў), была Simula як пашырэньне мовы Algol. Першай мовай праграмаваньня, якая атрымала назву «аб’ектна-арыентаваная», была Smalltalk.
Аб’ектна-арыентаванае праграмаваньне можна таксама разглядаць як набор аб’ектаў, якія ўзаемадзейнічаюць між сабой, што пярэчыць традыцыйным поглядам, калі праграма разглядаецца як сьпіс інструкцыяў для кампутара. У аб’ектна-арыентаваным праграмаваньні любы аб’ект здольны прымаць паведамленьні, апрацоўваць дадзеныя і адпраўляць паведамленьні іншым аб’ектам. Кожны аб’ект можа разглядацца як незалежная маленькая машына з пэўнай роляй або абавязкамі[2].
Тым ня менш, на сёньняшні дзень няма дасьледваньняў, якія б даказвалі, што аб’ектна-арыентаванае праграмаваньне аб’ектыўна лепшае, чым іншыя падыходы.
Фундамэнтальныя паняткі
рэдагавацьДэбара Армстранг (анг. Deborah J. Armstrong) правяла дасьледваньне кампутарнай літаратуры[3], якая выдавалася цягам апошніх 40 гадоў. У выніку гэтага дасьледваньня атрымалася вылучыць фундамэнтальныя паняткі, якія выкарыстоўваюцца ў пераважнай большасьці азначэньняў аб’ектна-арыентаванага праграмаваньня. Да іх належаць:
- Кляса вызначае абстрактныя характарыстыкі пэўнай сутнасьці, уключаючы характарыстыкі самой сутнасьці (яе атрыбуты або палі або ўласьцівасьці) і дзеяньні, якія яна можа выконваць (яе паводзіны або мэтады або магчымасьці). Напрыклад, кляса
Сабака
можа характарызавацца рысамі, якімі валодаюць усе сабакі: парода, колер футра, здольнасьць гаўкаць. Клясы дадаюць модульнасьць і структураванасьць у аб’ектна-арыентаваную праграму. Як правіла, кляса мусіць быць зразумелый для непраграмістаў, якія маюць пэўнае ўяўленьне пра прадметную вобласьць, што ў сваю чаргу азначае, што кляса мусіць мець значэньне ў кантэксьце. Але таксама код рэалізацыі клясы мусіць быць у пэўнай ступені самадастатковым. Уласьцівасьці і мэтады клясы разам называюцца ейнымі членамі.
- Канкрэтны экзэмпляр клясы. Кляса
Сабака
адпавядае ўсім сабакам шляхам апісаньня іх супольных рысаў; аб’ектЛэсьсі
— гэта пэўны сабака, з пэўным варыянтам значэньняў характарыстык.Сабака
мае футра;Лэсьсі
мае карычнева-белае футра. На жаргоне праграмістаў аб’ектЛэсьсі
зьяўляецца экзэмплярам клясыСабака
. Мноства значэньняў атрыбутаў пэўнай клясы называецца станам клясы.
- Магчымасьці аб’екта. Паколькі
Лэсьсі
— сабака, яна мае здольнасьць гаўкаць. Таму гаўкаць() зьяўляецца адным з мэтадаў аб’ектуЛэсьсі
. Ён можа мець і іншыя мэтады, напрыкладсядзець()
абоесьці()
. У праграме выкарыстаньне мэтада павінна ўплываць толькі на адзін аб’ект; усеСабака
могуць гаўкаць, але трэба, каб гаўкаў толькі адзін пэўны сабака.
- «Працэс перадачы дадзеных ад аднаго працэса іншаму, або дасыланьня іншаму запытаў на выкананьне мэтадаў»[3].
- У некаторых выпадках кляса таксама можа мець «падклясы» — больш спэцыялізаваныя вэрсіі клясаў. Напрыклад, кляса
Сабака
можа мець падклясыКольлі
,Чыхуахуа
іЁркшырскіТэр'ер
. У гэтым выпадкуЛэсьсі
будзе экзэмплярам падклясыКольлі
. Падклясы спадкуюць атрыбуты і паводзіны сваіх бацькоўскіх клясаў, а таксама могуць мець свае ўласныя. Няхай клясаСабака
мае мэтадгаўкаць()
і ўласьцівасьцьколерФутра
. Кожная з гэтых падклясаў (Кольлі
,Чыхуахуа
іЁркшырскіТэр'ер
) будзе спадкаваць гэтыя члены, а гэта азначае, што код для іх праграмісту трэба напісаць толькі адзін раз. Кожная падкляса можа зьмяніць свае спадкаваныя прыкметы. Напрыклад, клясаКольлі
можа вызначыць, што значэньнем па змоўчаньні ўласьцівасьціколерФутра
будзе карычнева-белы.Чыхуахуа
можа вызначыць мэтадгаўкаць()
як пранізьлівы па змоўчаньні. Падклясы могуць таксама дадаваць новых членаў. Напрыклад, падклясаЧыхуахуа
можа дадаць мэтаддрыжэць()
. Такім чынам, асобны экзэмпляр чыхуахуа можа выкарыстоўвацьгаўкаць()
прынізьліва ад падклясыЧыхуахуа
, які ў сваю чаргу спадкуе звычайнаегаўкаць()
адСабака
. Аб’ект чыхуахуа таксама будзе мець мэтаддрыжэць()
, але ўЛэсьсі
такога мэтада ня будзе, боЛэсьсі
— гэтаКольлі
, а неЧыхуахуа
. Спадкаваньне ўводзіць адносіны «ёсьць»:Лэсьсі
ёсьцьКольлі
,Кольлі
ёсьцьСабака
. ТамуЛэсьсі
спадкуе ўласьцівасьці абедзьвюх клясаў:Кольлі
іСабака
. Калі аб’ект ці кляса спадкуе ўласьцівасьці ад больш чым адной продкавай клясы, і ніводны з гэтых продкаў не зьяўляецца продкам іншага, тады гэта называецца множным спадкаваньнем. Напрыклад, могуць быць вызначаныя незалежныя клясыСабака
іКот
, але зь іх будзе створаны аб’ектХімэра
, які спадкуе паводзіны і сабакі, і ката. Але гэтая магчымасьць падтрымліваецца не заўсёды, бо можа быць дастаткова цяжка рэалізаваць і пасьля выкарыстоўваць тое, што атрымаецца.
- Хаваньне дэталяў, як працуе пэўная кляса, ад аб’ектаў, якія яе выкарыстоўваюць або адпраўляюць ёй паведамленьні. Так, напрыклад, кляса
Сабака
мае мэтадгаўкаць()
. Рэалізацыя гэтага мэтада апісвае, як мусіць адбывацца гаўканьне (напрыклад, спачаткуудыхнуць()
, а пасьлявыдыхнуць()
на выбранай частаце і гучнасьці). Пятро, гаспадарЛэсьсі
, не павінен ведаць, як яна гаўкае. Інкапсуляцыя дасягаецца шляхам пазначэньня, як клясы могуць зьвяртацца да членаў аб’екта. Як вынік, кожны аб’ект прадастаўляе любой клясе пэўны інтэрфэйс — члены клясы даступныя іншым клясам. Інкапсуляцыя патрэбная для таго, каб прадухіліць выкарыстаньне кліентамі інтэрфэйсу тых частак, якія, хутчэй за ўсё, будуць зьмененыя. Гэта дазволіць палегчыць унясеньне зьменаў, бо для гэтага ня будзе патрэбы зьмяняць карыстальнікаў інтэрфэйсу. Напрыклад, інтэрфэйс можа гарантаваць, што шчаняты могуць дадавацца да аб’ектаў клясыСабака
толькі кодам самой клясы. Часта члены клясы пазначаюцца як агульны (анг. public), абаронены (анг. protected) і асабісты (анг. private), вызначаючы, даступныя яны ўсім клясам, падклясам ці толькі клясе, у якой яны вызначаныя адпаведна. Пэўныя мовы праграмаваньня ідуць яшчэ далей: Java выкарыстоўвае ключавое слова protected для абмежаваньне доступу, які будзе дазволены таксама з клясаў з таго ж пакета, C# і VB.NET абмяжоўваюць выкарыстаньне пэўных членаў толькі клясамі з той жа зборкі выкарыстоўваючы ключавыя словы internal (C#) або Friend (VB.NET), а Eiffel і C++ увогуле дазваляюць пазначаць, якія клясы могуць атрымаць доступ да любога члена.
- Спрашчэньне складанай рэчаіснасьці шляхам мадэляваньня клясаў, якія падыходзяць для разьвязаньня праблемы, і работа на ўзроўні дэталізацыі, які найлепшым чынам падыходзіць для разьвязаньня акрэсьленых аспэктаў праблемы. Напрыклад
Сабака
Лэсьсі
большую частку часу можа разглядацца якСабака
, калі патрэбна атрымаць інфармацыю, спэцыфічную для сабак пароды кольлі, — якКольлі
і якЖывёла
(магчыма, бацькоўская кляса для клясыСабака
) для пераліку хатніх жывёлаў Пятра.
- Палімарфізм — здольнасьць клясы выкарыстоўваць паводзіны ў залежнасьці ад умоваў, у якіх гэтыя паводзіны патрабуюцца, то бок два ці большая колькасьць клясаў могуць рэагаваць па-рознаму на аднолькавыя паведамленьні. Напрыклад, калі
Сабака
атрымлівае камандуголас()
, то ў адказ можна атрымацьГаў
; а каліСьвіньня
атрымлівае камандуголас()
, то ў адказ можна атрымацьРох
. Гэтыя паводзіны і чакаюцца, таму штоСьвіньня
мае канкрэтную рэалізацыю мэтадаголас()
. Тое самае адбываецца з клясайСабака
. Улічваючы, што абодва зь іх спадкуюцьголас()
адЖывёла
, гэта прыклад перавызначальнага палімарфізму.
Прататыпна-арыентаванае праграмаваньне
рэдагавацьНя ўсе з вышэй пералічаных канцэпцыяў прысутнічаюць ва ўсіх аб’ектна-арыентаваных мовах праграмаваньня. Напрыклад, у прататыпна-арыентаваным праграмаваньні не выкарыстоўваюцца клясы. Як вынік, для вызначэньня паняткаў аб’ект і экзэмпляр выкарыстоўваецца значна адрозная, але падобная тэрміналёгія, хаця ў гэтых мовах і адсутнічаюць аб’екты.
Рэалізацыйны падыход
рэдагавацьРэалізацыйны падыход заключаецца ў тым, што кожны аб’ект у аб’ектыўна-арыентаваным праграмаваньні мае свой тып (клясу). Кляса ў сваю чаргу зьяўляецца пэўным тыпам дадзеных, які ўтрымлівае ў сабе:
- Палі зьвестак
- Парамэтры аб’екта, якія неабходныя праграме і якія задаюць стан аб’екта (уласьцівасьці аб’екта прадметнай вобласьці). Часам узьнікае блытаніна, калі палі зьвестак аб’екта называюць ягонымі ўласьцівасьцямі.
- Мэтады
- Дзеяньні, якія можна выконваць з аб’ектам тагога тыпу або якія можа выконваць сам аб’ект.
- Уласьцівасьці
- Значэньні, якія даступныя на чытаньне і/альбо запіс праз мэтады, якія называюцца аксэсарамі (ад анг. access — доступ). Гэтыя мэтады звычайна называюцца гетэрамі (чытаньне) і сэтэрамі (запіс). Яны забясьпечваюць чытаньне і вызначэньне значэньняў палёў дадзеных, зьвязаных з уласьцівасьцямі. Уласьцівасьці можна разглядаць як «разумныя» палі дадзеных, якія суправаджаюць доступ да поля дадзеных якімі-небудзь дадатковымі дзеяньнямі (напрыклад, перамылёўка аб’екта пры зьмене ягоных каардынатаў).
Канцэптуальны падыход
рэдагавацьКожны аб’ект зьяўляецца экзэмплярам пэўнай клясы. Адна кляса адрозьніваецца ад іншай імем і, звычайна, наборам інтэрфэйсаў, якія падтрымліваюцца. Інтэрфэйсы, у сваю чаргу, зьяўляюцца наборам паведамленьняў, якія можна адпраўляць аб’екту.
Крытыка
рэдагаваць- Дасьледваньне Томаса Потака і інш.[4] паказала адсутнасьць значнай розьніцы ў прадуктыўнасьці распрацоўкі праграмнага забесьпячэньня паміж аб’ектна-арыентаваным праграмаваньнем і працэдурным падыходам.
- Крыстафэр Дэйт паказвае на немагчымасьць параўнаньня аб’ектна-арыентаванага праграмаваньня і іншых тэхналёгіяў пераважна з-за таго, што адсутнічае строгае і агульнапрынятае вызначэньне аб’ектна-арыентаванага праграмаваньня[5].
- Аляксандар Сьцяпанаў высунуў ідэю, што аб’ектна-арыентаванае праграмаваньне абмежаванае матэматычнай мадэльлю і зьяўляецца, па сутнасьці, такой самай містыфікацыяй, як і штучны інтэлект[6].
- Фрэдэрык Брукс у артыкуле «No Silver Bullet. Essence and Accidents of Software Engineering» (Computer Magazine; красавік 1987) заўважае, што найбольш складанай часткай стварэньня праграмнага забесьпячэньня зьяўляецца «…спэцыфікацыя, дызайн і тэставаньне канцэптуальных канструкцыяў, а зусім ня праца па рэалізацыі гэтых канцэптуальных канструкцыяў…». Аб’ектна-арыентаванае праграмаваньне, на ягоную думку, ня можа зьнізіць складанасьць распрацоўкі праграмных сыстэмаў. Па ягоным меркаваньні «…аб’ектна-арыентаванае праграмаваньне дазваляе спрасьціць толькі прыўнесеную складанасьць у рэалізацыі дызайна. Дызайн застаецца складаным па сваёй прыродзе…»[7].
Крыніцы
рэдагаваць- ^ Мэер (Meyer), разьдзел 3
- ^ Буч (Booch), разьдзел 2
- ^ а б Армстранг (Armstrong), «The Quarks of Object-Oriented Development». У парадку зьмяншэньня распаўсюджанасьці былі вылучаныя наступныя паняткі: спадкаваньне, аб’ект, кляса, інкапсуляцыя, мэтад, перадача паведамленьняў, палімарфізм, абстрагаваньне
- ^ http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf
- ^ C. J. Date, Introduction to Database Systems, выданьне 6-е, старонка 650
- ^ http://www.stlport.org/resources/StepanovUSA.html
- ^ https://web.archive.org/web/20070315075634/http://inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html