Мінез-құлықты кіші түрге келтіру - Behavioral subtyping

Жылы объектіге бағытталған бағдарламалау, мінез-құлықты кіші түрге келтіру синтаксистік қауіпсіздік (мысалы, «табылмаған» қателіктердің болмауы) сияқты емес, сонымен қатар мінез-құлықтың дұрыстығына қатысты суперкласс типіндегі сілтемелер арқылы ішкі сынып объектілеріне кіретін клиенттердің үміттерін ішкі сыныптар қанағаттандыруы керек. Нақтырақ айтқанда, объектінің болжамды түрінің спецификациясын пайдалана отырып, клиенттер дәлелдей алатын қасиеттер, егер объект іс жүзінде осы типтің кіші түрінің мүшесі болса да, болуы керек.[1]

Мысалы, екеуінде де болатын Stack типін және кезек түрін қарастырыңыз қойды элементті қосу әдісі және а алу біреуін жою әдісі. Осы типтермен байланысты құжаттама Stack типінің әдістері стектер үшін күтілгендей жұмыс істейтіндігін анықтайды делік (яғни олар көрсетуі керек) ЛИФО кезек күтудегідей әрекет етуі керек (яғни олар кезектеседі) ФИФО мінез-құлық). Енді Stack типі кезек түрінің ішкі класы ретінде жарияланды делік. Бағдарламалау тілінің көптеген компиляторлары құжаттаманы елемейді және сақтау үшін қажет тексерулерді ғана орындайды қауіпсіздік түрі. Кезек типінің әрбір әдісі үшін Stack типі сәйкес аты мен қолтаңбасы бар әдісті ұсынатындықтан, бұл тексеру сәтті болады. Дегенмен, кезек типіне сілтеме арқылы Stack объектісіне кіретін клиенттер кезек құжаттамасына сүйене отырып, FIFO мінез-құлқын күтеді, бірақ LIFO тәртібін бақылайды, бұл клиенттердің дұрыстығының дәлелдерін жарамсыз етеді және тұтасымен бағдарламаның дұрыс емес жұмысына әкелуі мүмкін.

Бұл мысал мінез-құлық ішкі түрін бұзады, өйткені Stack типі кезек типінің типтік кіші түрі емес: Stack типіндегі құжаттамамен сипатталған мінез-құлық (яғни LIFO мінез-құлқы) кезек типінің құжаттамасына сәйкес келетін жағдай болмайды (ол үшін FIFO әрекеті қажет) .

Керісінше, Stack және Queue екеуі сипаттамалары бар Bag типті ішкі сыныптары болып табылатын бағдарлама алу тек жояды кейбіреулері элемент, мінез-құлықтың кіші типін қанағаттандырады және клиенттерге олардың өзара әрекеттесетін объектілерінің болжамды типтері негізінде дұрыс туралы сенімді түрде ойлауға мүмкіндік береді. Шынында да, Stack немесе Queue сипаттамаларын қанағаттандыратын кез-келген объект пакеттің сипаттамасын қанағаттандырады.

S типінің T типінің мінез-құлық кіші түрі болып табылатындығы тек тәуелді болатындығын баса айтқан жөн сипаттама (яғни құжаттамаT типті; The іске асыру T типті, егер ол бар болса, бұл сұраққа мүлдем қатысы жоқ. Шынында да, T типіне тіпті енгізу қажет емес; бұл таза абстрактілі класс болуы мүмкін. Жоғарыда келтірілген тағы бір жағдай ретінде, жоғарыдағы Stack типі Bag типті болса да, Bag типті мінез-құлықтың кіші түрі болып табылады іске асыру FIFO мінез-құлқын көрсетеді: маңыздысы бұл пакеттің түрі сипаттама әдіс арқылы жойылған элементті көрсетпейді алу. Бұл сонымен қатар мінез-құлық кіші типін әр қатысушы түріне қатысты нақты (мінез-құлық) спецификацияға қатысты талқылауға болатындығын, егер қатысушы типтерде нақты мінез-құлық спецификациясы болмаса, мінез-құлық кіші типін мағыналы түрде талқылауға болмайтындығын білдіреді.

Мінез-құлықтың кіші түрін тексеру

S типі - бұл T типінің мінез-құлық ішкі түрі, егер S сипаттамасымен рұқсат етілген әрбір мінез-құлыққа сонымен бірге T спецификациясымен рұқсат етілсе, бұл, атап айтқанда, әр M әдісі үшін M-дің S-дегі спецификациясы қажет. күшті Т-дағыдан гөрі

Берілген әдіс сипаттамасы алғышарт Pс және а кейінгі шарт Qс алғышартпен берілгеннен күштірект және кейінгі жағдай Qт (ресми түрде: (Pс, Qс) ⇒ (Pт, Qт)) егер Pс болып табылады әлсіз қарағанда Пт (яғни Pт бұл Pс) және Qс Q-дан күштіт (яғни Qс дегенді білдіреді Qт). Яғни, әдіс сипаттамасын күшейту посткондицияны күшейту арқылы жасалуы мүмкін әлсіреу алғышарт. Шынында да, әдіс спецификациясы әлдеқайда күштірек, егер ол қолдауға ие болған кірістер үшін белгілі бір шектеулер туғызатын болса немесе оған қосымша кірістер қажет болса.

Мысалы, аргументтің абсолюттік мәнін есептейтін әдіс үшін (өте әлсіз) спецификацияны қарастырыңыз х, бұл 0 ≤ x алғышартты және 0 ≤ кейінгі жағдайды анықтайды. Бұл спецификация әдіс теріс мәндерді қолдамауы керек дейді хБұл тек нәтиженің теріс емес болуын қамтамасыз етуі керек. Осы спецификацияны күшейтудің екі мүмкін әдісі = = x | күйінің кейінгі шарттарын күшейту, яғни нәтиже х-тің абсолютті мәніне тең немесе «шын» алғышарттарын әлсірету, яғни барлық мәндер х қолдау керек. Әрине, біз екеуін де нәтиженің абсолюттік мәніне тең болуы керек болатын спецификацияға біріктіре аламыз х, кез келген мәні үшін х.

Алайда сипаттаманы күшейтуге болатындығын ескеріңіз ((Pс, Qс) ⇒ (Pт, Qт)) кейінгі жағдайды нығайтпай (Qс ⇏ Сұрақт).[2][3] 0 ≤ x алғышартты және кейінгі шарт = x нәтижесін анықтайтын абсолютті мән әдісі үшін сипаттаманы қарастырыңыз. «Шын» алғышарт пен кейінгі шарттың нәтижесін көрсететін спецификация = | x | кейінгі шарт нәтижесі болса да, бұл спецификаны күшейтеді = | x | кейінгі жағдай нәтижесін күшейтпейді (немесе әлсіретпейді) = x. Алғышартпен спецификацияның қажетті шартыс және кейінгі жағдай Qс алғышартпен сипаттамадан гөрі күшті Pт және кейінгі жағдай Qт бұл Pс P-ге қарағанда әлсізт және «Qс немесе жоқс«Q» қарағанда күштіт немесе жоқт«. Шынында да,» нәтиже = | x | немесе жалған «күшейтеді» нәтижесі = x немесе x <0 «.

«Орынбасарлық»

Негізгі маңызды үндеуде[4] OOPSLA 1987 бағдарламалау тілінің ғылыми-зерттеу конференциясында деректерді жинау және класс иерархиялары туралы, Барбара Лисков мынаны айтты: «Мұнда келесі ауыстыру қасиеті сияқты нәрсе қажет: егер әр объект үшін S типті объект бар T түріндегі барлық P бағдарламалары үшін P әрекеті өзгермеген кезде ауыстырылады , содан кейін S - бұл Т-нің кіші түрі. «Бұл сипаттама содан бері кең танымал болды Лисковты алмастыру қағидасы (LSP). Өкінішке орай, оның бірнеше мәселелері бар. Біріншіден, оның түпнұсқалық тұжырымдамасында ол тым күшті: біз кіші сыныптың мінез-құлқын оның суперкластың мінез-құлқымен бірдей болғанын сирек қалаймыз; кіші класс объектісін суперкласс объектісіне ауыстыру көбінесе бағдарламаның мінез-құлқын өзгерту үшін, егер мінез-құлық кіші түрін құрметтейтін болса, бағдарламаның қажетті қасиеттерін сақтай отырып жасалады. Екіншіден, бұл туралы ештеңе айтылмаған сипаттамалары, сондықтан ол қате оқуға шақырады, онда іске асыру S типін салыстырады іске асыру T типті. Бұл бірнеше себептерге байланысты проблемалы болып табылады, себебі ол T-дің абстрактілі және орындалуы жоқ жалпы жағдайды қолдамайды. Үшіншіден, және объектінің бағдарланған императивті бағдарламалау контекстінде белгілі типтегі объектілерге жалпыға бірдей немесе экзистенциалдық сандық мән берудің немесе бір объектіні басқасына ауыстырудың нені білдіретінін нақты анықтау қиын.[3] Жоғарыдағы мысалда біз Stack объектісін Bag объектісіне ауыстырмаймыз, жай Stack объектісін Bag объектісі ретінде қолданамыз.

2016 жылы берген сұхбатында Лисков өзі өзінің негізгі баяндамасында «бейресми ереже» болғанын түсіндіреді, кейінірек Жаннет Винг оларға «бұл нені білдіретінін дәл анықтауға тырысыңыз» деген ұсыныс жасады, бұл олардың бірлесіп жариялануына себеп болды[1] мінез-құлықты кіші түрлендіруге және «техникалық тұрғыдан бұл мінез-құлықты кіші түрлендіруге» деп атайды.[5] Сұхбат кезінде ол тұжырымдамаларды талқылау үшін ауыстыру терминологиясын қолданбайды.

Ескертулер

  1. ^ а б Лисков, Барбара; Қанат, Жаннет (1994-11-01). «Бөлшектеудің мінез-құлық түсінігі». Бағдарламалау тілдері мен жүйелері бойынша ACM транзакциялары. 16 (6): 1811–1841. дои:10.1145/197320.197383.
  2. ^ Паркинсон, Мэттью Дж. (2005). Java үшін жергілікті пікір (PDF) (PhD). Кембридж университеті.
  3. ^ а б Ливенс, Гари Т .; Науманн, Дэвид А. (тамыз 2015). «Мінез-құлықты кіші түрлендіру, спецификация мұрасы және модульдік пайымдау». Бағдарламалау тілдері мен жүйелері бойынша ACM транзакциялары. 37 (4). дои:10.1145/2766446.
  4. ^ Лисков, Б. (Мамыр 1988). «Негізгі мекен-жай - деректерді абстракциялау және иерархия». ACM SIGPLAN ескертулері. 23 (5): 17–34. дои:10.1145/62139.62141.
  5. ^ ван Влек, Том (20 сәуір, 2016). Барбара Лисковпен сұхбат. ACM.

Әдебиеттер тізімі

  • Паркинсон, Мэттью Дж.; Биерман, Гэвин М. (қаңтар 2008). «Бөлу логикасы, абстракция және мұрагерлік». ACM SIGPLAN ескертулері. 43 (1): 75–86. дои:10.1145/1328897.1328451.