Обектно ориентирано програмиране (ООП): полиморфизъм

Програмирането е процес на разработване на решения за "живи" динамични задачи под формата на твърди кодови структури, данни, функции и алгоритми. Процедурата за формиране на строг синтаксис от несигурна семантика. Реалните задачи са известен голям проблем в смисъл на

ООП се опита два пъти да "счупи" тази древна концепция за програмиране, но "оковите" на класическия стил на кодиране на данни и алгоритми са все още силни.

Ниво и квалификация

Компютърните науки започнаха с изчисления, но скоростта, с която се увеличава ускоряването на движението в сферата на обработката на информацията, все още не е достатъчно голяма, за да стане невъзможно класическото програмиране и да престане да съществува.

Обективно и това, което разработчикът не настоява, а клиентът не изисква реално решение на реални проблеми. Двете страни са свикнали да се ограничават до наличните инструменти и обичайни възможности.

Формите на полиморфизма на ООП, идеята за капсулиране на кода и наследяването на свойствата (методите) се намират в областта на програмирането, но не и в обхвата на проблема, който се решава.

Добър пример е библиотеката PHPOffice / PHPWord. За да го използвате, се нуждаете от квалификация на разработчика, трябва да създадете своя собствена система от обекти, но текущото ниво на клиента (изисквания на клиента) е тривиален състав, който програмистът заменя, като развива (в противен случай изискванията няма да бъдат изпълнени). Положението е така:

В този случай използването на библиотеката е задачата за форматиране на документи, например, диплома или теза трябва да бъдат стандартизирани. Клиентът представи своите искания и програмистът продължи своя път.

Завършва пълен анализ на документа, сглобява го в необходимия формат, изпълнява работа с таблици на всяко ниво на гнездене, сливане и разделяне на клетки, отпечатване във всяка посока и т.н.

Полиморфизъм и ООП

Най-доброто определение за полиморфизма не е да разберем как да се позовем на историята на развитието на идеята за обектно-ориентирано програмиране, толкова популярно сега, толкова често използвано, но неосъзнат по същество все още.

Всеки автор има своето собствено понятие за началото и същността на ООП. За всеки внимателен читател тази концепция е правилна и обективна. Но до днес всеки приема като безусловна аксиома само три позиции:

• капсулиране;
• полиморфизъм;
• наследяване.

Някои добавят: абстракция, а по-често тази, и наистина основната точка, се използва като основа за описване на същността на ООП.

Така че мненията за ООП са полиморфни: те описват едно нещо, те са проектирани по различен начин или, напротив, описват различни неща, но се основават на четири еднакви позиции.

Демократичното начало не е характерно за областта на информационните технологии, но трябва да се обърне внимание: комбинацията и съвместното съществуване на много мнения за едно и също нещо е истински полиморфизъм в действие.

Популярни определения на полиморфизма

OOP е следващият етап в развитието на информационните технологии. С това много малко хора твърдят, но основните аксиоми и позиции са толкова различни в частта от семантиката, че те не заслужават внимание извън тяхната цялост.

1. Полиморфизмът в програмирането е способността да се осигури един и същ интерфейс за различни основни форми (типове данни).
2. Полиморфизмът е способността на обектите да имат различно изпълнение.
3. Полиморфизмът е способността на функция ...
4. Класика (от създателя на C / C ++): "един интерфейс - много реализации".
5. Параметричният полиморфизъм означава ...
6. Полиморфизмът е позицията на теорията на типа ...
7. Абстракцията е невъзможна без капсулиране и наследяване, тъй като полиморфизмът без наследство е невъзможен ...

Човек може да се съгласи, че всичко това се отнася до едно и също нещо: но формата на изразяване на мисълта, същността и съдържанието не са подобни. Но има нещо обичайно.

Същност: разработчик-клиент

Класическото програмиране изисква присъствието на програмист и задачи (клиент, клиент). Програмистът разглежда проблема, формализира го и прави кода, който води до решението. Клиентът отрича всички предложени или само част от тях, като посочва недостатъци и програмистът върши отново работата си.

Този цикъл на процеса на решаване на проблема предполага, че две съвсем различни единици са ясно комбинирани тук:

• Компютърът не може да реши проблема сам по себе си;
• Необходима е програма, така че компютърът да може да "разбере" и да "реши" проблема.

Задачата е компетентността на клиента, програмата е алгоритъм за "приспособяване" на задачата към възможностите на компютъра - обхвата на компетентността на програмиста. Ролята на последната е да "адаптира" компютъра към изискванията на задачата и това е излишно!

Обектно-ориентирано програмиране предлага абстрактен. Има обекти - това е обхватът на клиента - е изпълнението на обекти - това е обхватът на програмиста. Няма "технологична" връзка между клиента и разработчика. Идеята е кардинала, която не се реализира до ден днешен, но нещо вече работи постоянно.

Windows, бутони и други обекти

Историята на Air Art Technology, Object Magazine, Turbo Vision, Graph Vision е история. Малко хора си спомнят реализацията на ООП, те не се използват и забравени, но прозорец Windows интерфейс е позната на милиони потребители, както и обекти в PHP среди, jаvascript и други езици Интернет технологиите се използват от стотици хиляди код разработчиците знаете за тях милиони посетители на уеб ресурси.

Вероятно това е единственият правилен начин, по който трябва да се развива ООП: капсулиране, наследяване, полиморфизъм за разработчика, но не и за потребителя. Характерно е, че тази позиция е основна при разработването на визуалния дизайн (интерфейс) на софтуера на Windows, приложен програмите като Turbo Vision и Graph Vision.

Концепцията зад продуктите на Air Art Technology и Object Magazine беше значително различна. Тук абстрактният обект е първият предшественик на информационната структура, капсулиран на абстрактно ниво на кода за обработка на информацията. Обекти на прозорци, копчета, визуални елементи тук бяха вторични.

В първата версия (Windows и т.н.) OOP парадигма: капсулиране, наследяване, полиморфизъм определен абстрактно ниво предшественик и код изпълнение формира на нивото на всеки отделен дете наследство клон съгласно желаната структура и съдържание.

Във втория вариант (Air Art Technology и Object Magazine), нивото на абстрактния обект е важно. Какво ще се случи с определен потомък не е същността, основното е, че неговият клон на наследство отговаря на изискванията на всички родители до абстракцията на корените.

Обект и система от обекти: алгоритъм

Идеалната обектно-ориентирана концепция може да манипулира само обектни обекти и системи.

В съвременните езици за програмиране в рамките на обекта (клас) най-общо се разбира описание на обекта и инстанция на обекта, както и да се използва описанието на обекта езици позволяват на програмиста да работи със статични обекти, а динамичен обект - това е копие Описание, със своето уникално съдържание и структура, но използвайки същите описателни методи (свойства).

Настоящата практика се отнася до концепцията за обекта към инструмента, т.е. към програмния език, интерфейса, достъпа до базата данни, връзката по мрежата, но няма нищо, което да сочи интересите на клиента по решаването на проблема.

Това е идеално за прости OOP: полиморфизмът позволява да се правят по-специално разнообразни дизайнерски елементи, но да се управляват с един и същ код. Но тук няма съмнение относно обектите на проблема, който изобщо не се разглежда като обект на обектно-ориентиран анализ.

Програмистите приемат ООП като средство за подобряване на качеството и производителността на своята работа, но те не губят капка от своята територия на клиента. Основните понятия за ООП - капсулиране, наследяване, полиморфизъм - останаха в сферата на развитието и не бяха трансплантирани в обхвата на проблема.

Обект и система от обекти: задача и решение

Компютърен програмист е задача. Средната връзка е излишна. В идеалния случай трябва да има само два, относително зависими контури: (компютър - програмист) - задачата. Това означава, че потребителят, клиентът или посетителят имат инструмент за решаване на тяхната задача. Как се прилага инструментът, клиентът не го е грижа.

В идеалния случай това е просто компютър, който може да разбере какво иска клиентът и да направи това, което иска. Как ще изглежда: локална програма или сайт, достъпен чрез браузър, специална програма за разпределена обработка на информация, информационна система за клиента - това няма значение.

От съществено значение е да няма излишна връзка между задачата и компютъра, но първата е разбираема и може да бъде решена от втория. За да се постигне тази цел, компютърът и клиентът трябва да бъдат свързани чрез една система от обекти, значението, структурата и съдържанието на всеки обект се определя от клиента, а методите и свойствата на обектите се изпълняват от програмиста.

В идеалния случай, когато работата на клиента за създаване на необходимата система от обекти и работа по внедряване на методи и свойства на тези обекти са отделени от времето. Колкото по-отдалечено е внедряването на системата от обекти (програмист) от семантичното му съдържание (клиента), толкова по-добър е процесът.

Нищо не възпрепятства клиента и програмиста да взаимодействат в процеса на решаване на проблема, но е важно да има ясно разделение на семантиката. Всеки трябва да си вършат работата, програмистът не е необходимо да се развие в обхвата на проблема, и клиентът не разбира кода и така още повече, страните не трябва да се даде на всеки друг съвет, че не ги засяга.

Традиционно и обектно програмиране

Основна PLO постулира: капсулиране, наследяване, полиморфизъм във формата, в която те са свикнали и заяви, доведе до значително подобрение на качеството и надеждността на код значително ускоряване на програмиране на работни места и има много други положителни качества.

Но това все още е там: класическото програмиране не е по-ниско от неговите позиции, а много обективно ориентирани идеи се прилагат от класическия код.

Въпреки това, идеята за освобождение на Палестина и рекурсия доведе до адекватно влияние върху синтаксиса на класическата синтаксис оператори, логиката на конструиране на нормалната код, без да има никакво отношение към обектно-ориентиран стил на писане и мислене.

Списъци и завийте, самото понятие в първия и последния елемент на масива, имаше цикъла "всеки" и справка за именуване опции, използва и производителност са станали по-популярни от всякога.

Всъщност фактът, че променливите са загубили своята "ясно" лице (тип променлива може да се промени, ако е необходимо, и да описват променливата не е необходимо), казва, че класиците, всъщност, отдавна превърнали в обектно-ориентираното и призната от основните принципи на обектно-ориентиран: капсулиране , наследство, полиморфизъм като идеи със значително значение.

Какво е в основата: обект или система

Абстракция, като основен идеен позиция на ООП, без значение къде зоната на отговорност (изпълнение) на обекта - на първо един абстрактен обект, или на нивото на конкретен потомство, - оставя отворен въпроса: как започна всичко, имащо за цел или със системата?

Ако обектът се основава на обекта, той никога няма да стане система, тъй като системата ще бъде в нея и ще се превърне в твърд образ на много конкретно начало. Тук, с абстракция, възникват проблеми: първоначалният обект прецизно улавя главния в решаването на проблема, т.е. той вече не пренася към друга задача.

Ако системата се основава на обекти, тогава се получава система от системи. Трудно е да си представим във връзка със специфична задача и къде да започнем да се развиваме е трудно да се разбере. Като цяло, полиморфизмът на ООП с неговите различия в обектите, формите на изпълнение, количествата на действителните параметри във функциите дава идея за системата, която се намира в началото, като:

• за опциите за решаване на проблема (например менюто);
• за началните условия (прилагане на проблема при различни условия, данни);
• за начините на работа (тестване, настройка, работа).

Но това и подобните не му дават основание да се базира решението на проблема на система от обекти. Често е достатъчно да се определи един единствен първоначален обект.

История на процеса на решаване на проблеми

Най-важните принципи на ООП: полиморфизъм и абстракция - определят приоритета на първоначалния обект като система от обекти. При спор, който трябва да бъде по-ранен, пиле или яйце, победата отива на пилето.

Няма съмнение, че всичко трябва да започне с абстрактен обект, а не със система от обекти. Но като се има предвид факторът време и да го прилага на нивото на всеки обект, като се започне още от първия абстрактно, а след спорна идея да се постави в началото на разтвора и на обекта, а системата е единственото разумно.

Ако класическата концепция за програмиране в хода на решаване на проблема се променя съдържанието на данните в базата данни, модифицира файлове и т.н., Концепцията за обектно-ориентиран на полиморфизъм, капсулиране и факторът време да промени съдържанието, структурата и свойствата на обекти в проблем на системата, за да бъде решен.

Обектно-ориентиран програмист-малко се интересуват от идеята за даден файл, база данни, алгоритъм - конкретен програмист мисли обекти, но съществуват обектите във времето и да промени хода на постигане на желаното.

Така, в началото на системата е обект на обекти и логиката на тази система - времеви график: начало проблем, формирането на първия обект, вход или събиране на данни, след формирането на обекта, но нищо не пречи първият обект, за да започне на следващия решение.

Всяко ниво на обекти действа като независима система от обекти, т.е. е един обект, но в контекста на започналия процес и стойността на времето е система от обекти на времевата скала. За пълното прилагане на ООП полиморфизъм, наследяване и факторът време комбинират, за да се осигури динамиката на първия, т.е., не само може да се промени с течение на времето, но и да доведе до обекти, които не са предоставени от възложителя, генерирани в хода на изпълнение на задачите на процеса, очаква клиента.

Реалният ПОО полиморфизъм, например

Сложността на задачите, които силите на ООП не са съпоставими с тези, които са достъпни за класическата версия на писателските програми. Разбира се, решаването на всеки проблем винаги е налице по обичайния начин, но въпросът колко ще струва това време и усилия често прави резултата безполезен.

Не много отдавна е създадена библиотеката PHPOffice / PHPWord, но за да се използват нейните възможности, вие почти винаги трябва да създавате собствена система от обекти. Например, един прост * .docx файл:

е zip-архив на много файлове и папки във формат Office Open XML (OpenXML, OOXML). Всеки файл се записва в XML тагове, с при добавяне, промяна и изтриване на букви, думи, таблици, списъци, и така нататък. Елементи на съдържанието на файловете започва да представлява последователност от етикети, които не винаги са съдържат пълни елементи, един елемент често се вписва няколко маркера.

Ако представите този файл като поредица от маркери, ще получите интересна картина:

Лесно е да се види, че първият и единствен параграф на документа е представен от набор от тагове. Що се отнася до таблицата и нейните вградени таблици, обемът на описанието на всички елементи не е възприемчив към възприятието, но е достъпен за обектно-ориентираното приложение.

В действителност, на фигурата зеленото е изходното изпробване на маркерите, жълто е параметрите и типа на маркера, бежовото е съдържанието. Създадените обекти са ориентирани към машинна обработка. За даден човек са налице само операции за отваряне на файл с документи, форматиране и записване.

Решението е просто и практично, но изпълнението е по-скоро компютърно-ориентирано, отколкото човешко, поради големия брой изпълнени функции и сложните взаимоотношения между обектите.

Състояние на ООП региона

Разработването на системи за управление на сайтове, конфигуриране на сървъри и технологии за управление, опит в разработването на динамични сайтове направиха обектно-ориентирано програмиране, достъпно за всички. Проблемът е как да промените мисленето си и да свикнете с мислене на нивото на обектите, а не в контекста на последователно изпълнимия код.

Обикновено преходът от класическо програмиране към обектно ориентирано отнема от два до три месеца, но разходите се изплащат с лихва. Потенциалът на съвременните програмни езици, предимно PHP и jаvascript, ще задоволи най-сложния разработчик.

Модерен ООП - полиморфизъм, наследяване и възможността за формиране на свойствата на обекти - удобно и практично, синтаксис, както и инструменти за подкрепа осигуряват комфорт в работата и ефективността на код.

Перспективи на обективната идея

Колко време ще се случи класическото програмиране и как ще се развие ООП? Трудно е да се каже. Очевидно разработчиците на инструменти не планират да обмислят контекста на потребителя (потребител, клиент).

ОП инструменти - полиморфизъм, наследяване, капсулиране и абстракция - са ориентирани към разработчика.

Съвременни информационни системи и уеб-базирани ресурси са склонни да отговаря на действителността, за да се гарантира функционирането на реални обекти и да се създаде среда за тях, за да работят, толкова просто, че тя ще бъде достъпна за потребителя, далеч от програмирането, напълно потопен в сферата на своята компетентност.