Програмирането е процес на разработване на решения за "живи", динамични задачи под формата на твърди структури на код, данни, функции и алгоритми. Процедурата за формиране на строг синтаксис с несигурна семантика. Истинската задача е добре известният голям проблем в смисъла на алгоритмизацията: за да се постигне желаното решение, задачата трябва да бъде поставена в точни синтактични конструкции.
PLO два пъти се опита да "прекъсне" тази дългогодишна концепция за програмиране, но "оковите" на класическия стил на кодиране на данни и алгоритъм все още са силни.
Ниво и квалификация
Компютърният случай започна с изчисления, но скоростта, с която ускоряването на движението в областта на обработката на информация се увеличава, все още не е достатъчно голяма, за да стане класическото програмиране невъзможно и престане да съществува.
Обективно и фактът, че предприемачът не настоява, а клиентът не изисква реално решение на реалните проблеми. И двете страни са свикнали да се ограничават с наличните инструменти и навици. Формите на полиморфизъм на ООП, идеята за инкапсулиране на кодове и наследяването на свойствата (методите) са в областта на програмирането, но не и в областта на решаване на проблема. Пример за това е библиотеката PHPOffice /PHPWord. За да го използвате изисква квалификация на разработчика, трябва да създадете своя собствена система от обекти, но сегашното ниво на клиента (изисквания на клиента) - тривиален състав, който програмистът се припокрива с неговото развитие (в противен случай не отговарят на изискванията). Ситуация като тази:
БЗа този случай на използване на библиотеката проблемът с форматирането на документи, например, диплома или дисертация, трябва да бъде проектиран в съответствие със стандарта. Клиентът представи изискванията си, а програмистът продължи по своя път.
Пълен анализ на документа, неговото събиране в правилния формат, работа с таблици на всяко ниво на гнездене, сливане и разделяне на клетки, печат във всяка посока и т.н.
Полиморфизъм и ООП По-добра дефиниция за полиморфизма не е да се мисли как да се разчита на историята на развитието на идеята за обектно-ориентирано програмиране, толкова популярно в наши дни, толкова често използвано, но нереализирано в същността си до ден днешен. Всеки автор има собствена концепция за началото и характера на ООП. За всеки внимателен читател тази концепция е надеждна и обективна. Но до ден днешен всички приемат като безусловна аксиома само три позиции:
капсулиране; полиморфизъм; наследяване.Някои добавят повече: абстракция, и най-вече това, и всъщност основната точка, се използва като основа за описване на характера на ООП.
Следователно гледните точки на ООП са полиморфни: те описват едно, конструирано по различен начин, или, обратно, описват друго, но се основават на четири еднакви позиции. Демократичният произход не е типичен за областта на информационните технологии, но трябва да се отдаде почит: съчетанието и съжителството на много идеи за едно и също нещо е истински полиморфизъм в действие.
Популярни определения на полиморфизма
ООП - следващият етап в развитието на информационните технологии. стези няколко твърдят, но основните му аксиоми и разпоредби са толкова различни по отношение на семантиката, че не заслужават внимание извън тяхната цялост.
Полиморфизъм в програмирането е способността да се осигури един и същ интерфейс за различни базови форми (типове данни). Полиморфизъм - възможността обектите да имат различно приложение. Полиморфизъм е способността на функцията Класика (от създателя C /C ++): "един интерфейс - много реализации." Параметричен полиморфизъм означава Полиморфизъм - позицията на теорията на видовете Абстракцията е невъзможна без капсулиране и наследяване, като невъзможен полиморфизъм без наследство . и същото: но формата на изразяване на мисъл, същност и смисъл - не са подобни. Но има нещо общо.
Същност: разработчик - клиент
Класическото разработване на софтуер включва присъствието на програмист и задача (клиент, клиент). Програмистът разглежда задачата, го формализира и прави кода, който води до изпълнение. Клиентът отрича всички предложени или само част от него, като посочва недостатъците, а програмистът си върши работата отново. Такъв цикъл на процеса на решаване на проблема предполага, че има ясно два напълно различни обекта:
компютърът не може да реши самия проблем; изисква програма, така че компютърът да може да "разбере" и "да разреши проблема".Задача - сферата на компетентност на клиента, програмата е алгоритъм за "адаптиране" на задачата към възможностите на компютъра - компетентността на програмиста. роляпоследното е да "адаптира" компютъра към изискванията на задачата, а това не е необходимо! Обектно-ориентираното програмиране предполага абстракция. Има обекти - това е сферата на клиента; е реализацията на обекти - това е полето на програмиста. Няма "технологична" връзка между клиента и разработчика. Идеята е кардинална, не е изпълнена досега, но нещо вече работи стабилно.
Прозорци, бутони и други предмети
Историята на технологията Air Art, списание за обекти, Turbo Vision, Graph Vision е история. Малцина си спомнят тези OOP реализации, те са почти неизползвани и забравени, но интерфейсът на Windows е познат на милиони потребители, а обекти в PHP, javascript и други езици на интернет технологиите се използват от стотици хиляди разработчици на кодове, милиони посетители знаят за тях. уеб ресурси Вероятно това е единственият правилен начин за развитие на ООП: капсулиране, наследяване, полиморфизъм за разработчика, но не и за потребителя. Характерно е, че тази позиция е в центъра на дизайна на визуалния дизайн (интерфейс) на софтуерните приложения на Windows, като Turbo Vision и Graph Vision.
Концепцията, която се основава на продуктите от типа Air Art Technology и Object Magazine, се различава значително. Тук абстрактният обект е първият прародител на информационната структура, капсулиран на абстрактно ниво кода за обработка на информация. Обекти на прозорци, бутони, елементи на визуализация тук бяха вторични. В първата версия (Windows и т.н.) парадигмата на ООП: капсулиране, наследяване, полиморфизъм се отразява на абстрактното нивопрародител, а реализацията на кода се формира на нивото на всеки конкретен потомък в клона на наследяване в съответствие с желаната структура и съдържание. Във втората версия (Air Art Technology и Object Magazine) важно ниво на абстрактен обект. Какво ще се случи с конкретен потомък - не е същността, най-важното е, че неговият клон на наследство отговаря на изискванията на всички родители до коренната абстракция.
Обект и система от обекти: алгоритъм
Идеалната обектно-ориентирана концепция може да манипулира само обектни и обектни системи. В съвременните езици за програмиране под обекта (клас) обикновено се разбира описанието на обекта и инстанцията на обекта, а за да се използва описанието на обекта, езиците позволяват на програмиста да работи със статични обекти, докато динамичният обект - Това е екземпляр на описанието, с неговото уникално съдържание и структура, но използва същите свойства за описание (описание).
Настоящата практика се отнася до понятието за обект за инструмент, т.е. до езика за програмиране, интерфейса, достъпа до базата данни, мрежовата връзка, но няма нищо, което да е показателно за интересите на клиента по решаващия проблем. Това е идеално за обикновена ООП: полиморфизмът позволява да се правят, по-специално, различни елементи на дизайна, но да се управляват с един и същ код. Но тук не става въпрос за обекти на задачата, което изобщо не се разглежда като обект за обектно-ориентиран анализ. Програмистите взеха ООП като средство за подобряване на качеството и изпълнението на работата си, но не отстъпваха на клиента. Основни понятия на ООП - капсулиране,наследство, полиморфизъм - остава в областта на развитието и не се трансплантира в обхвата на задачата. Обект и система от обекти: задачи и решения
Компютър - програмист - задача. Средната връзка е излишна. В идеалния случай трябва да има само два относително зависими контура: (компютър - програмист) - задача. Това означава, че потребителят, клиентът или посетителят има средство за решаване на неговия проблем. Като внедрен инструмент, клиентът не го е грижа.
В идеалния случай, това е просто компютър, който може да разбере какво иска клиентът и да прави това, което той иска. Как ще изглежда: местна програма или уебсайт, достъпни чрез браузър, специална програма за разпределена обработка на информация, информационна система за клиента - няма значение. От съществено значение е между задачата и компютъра да няма ненужни връзки, а първо да е разбираемо и да се реши второто. За постигането на тази цел компютърът и клиентът трябва да бъдат свързани с една система от обекти, а съдържанието, структурата и съдържанието на всеки обект се определя от клиента, както и методите и свойствата на обектите, реализирани от програмиста. Идеално, когато работата на клиента за създаване на обектна система, от която се нуждае, и работата по внедряването на методите и свойствата на тези обекти се разпределят във времето. Колкото по-нататъшното изпълнение на системните обекти (програмиста) от съдържанието му (клиент) ще се защитава, толкова по-добър процес. Нищо не пречи на клиента и програмиста да взаимодействат в процеса на решаване на проблема, но е важно да има ясно разделение на семантиката. Всеки трябва да прави свой бизнес, програмистът не е задължен да овладее районаприлагането на задачата, а клиентът не трябва да разбира кода и по-специално страните не трябва да си дават съвети един на друг, тъй като те не се отнасят.
Традиционно и обектно програмиране
Основни постулати на ООП: капсулиране, наследяване, полиморфизъм във формата, в която те стават обичайни и търсени, водят до забележими подобрения в качеството и надеждността на кода, значително ускоряват работата на програмиста и имат много други положителни качества.
Но те също са в движение: класическото програмиране не е по-лошо от позициите им, а много обектно-ориентирани идеи се изпълняват от класическия код. Въпреки това, идеите на ООП и рекурсия доведоха до адекватно влияние върху синтаксиса на класическите синтактични оператори, върху логиката на конструиране на редовен код, който няма нищо общо с обектно-ориентирания стил на писане и мислене. Списъците и опашките се промениха, появи се концепцията за първия и последния елемент на масива, имаше цикли "за всеки", а примерните варианти на именуване, използване и изпълнение станаха още по-популярни, отколкото преди. Всъщност самият факт, че променливите губят своя "ясен" човек (видът на променливата може да варира според нуждите, но описанието на променливата изобщо не е необходимо), казва, че класиката всъщност отдавна е обектно ориентирана и признава основните принципи на PLO: капсулиране наследство, полиморфизъм като идеи, които имат значително значение.
Основа: обект или система
Абстракция, като основна концептуална позиция на ООП, независимо от това къде се намира зоната на отговорност (изпълнение)обект - на нивото на първия абстрактен обект или на нивото на конкретен потомък - оставя отворен въпроса: откъде да започнем, от обекта или системата?
Ако основата е да постави обект, то никога няма да се превърне в система, защото системата ще бъде вътре в нея и той ще стане твърдо напълно конкретен старт. Тук, с абстракцията, има проблеми: първоначалният обект точно улавя основния проблем в решението, т.е. той вече не може да се прехвърля на друга задача. Ако в основата на поставянето на системата от обекти, след това на системата от системи. Трудно е да си представим по отношение на конкретна задача, от която да започнем развитието - също е трудно да се разбере. Като цяло, полиморфизмът на ООП с неговите различия по същество, форма на реализация, брой действителни параметри в функциите дава представа за системата, която се намира в началото, като:
за възможности за решаване на проблеми (например менюто); за началните условия (прилагане на задачата при различни условия, данни);
относно режимите на работа (изпитване, конфигуриране, работа).Но това и други подобни не му дават основание да постави основата за решаване на проблема с една система от обекти. Често е достатъчно да се дефинира един обект.
История на процеса на решаване на проблема
Най-важните принципи на ООП: полиморфизъм и абстракция - определят приоритетния обект като система от обекти. В спор, който трябва да бъде преди, пиле или яйце, победата тук получава пушач. Няма съмнение, че всичко трябва да започне с абстрактен обект, но не и от система от обекти. ноако вземем предвид фактора на времето и го приложим на нивото на всеки обект, започвайки с първия абстрактен текст, тогава противоречивата мисъл е да поставим решението и обекта в началото, а системата е единствената интелигентна. Ако класическата концепция за програмиране по време на решаването на проблема променя данните, съдържанието на базата данни, файловете за промени и т.н., концепцията за полиморфизъм на ООП, капсулирането и факторът на времето променят съдържанието, структурата и свойствата на обектите на системните обекти, които трябва да бъдат решени. Програмистът в ООП най-малко се интересува от концепцията за файл, база данни, алгоритъм - това е особено, тук програмистът мисли обекти, но обектите съществуват във времето и се променят в хода на желаното.
Така в началото обектът се намира като система от обекти и логиката на тази система - времевата линия: стартирането на задача, формирането на първия обект, въвеждането или събирането на данни, формирането на следващия обект, но нищо не пречи на първия да се противопостави на следващото решение. Всяко ниво на обекти действа като независима система от обекти, т.е. тя е един обект, но в контекста на инициирания процес и времевата стойност е система от обекти по времева скала. За пълното прилагане на ООП, полиморфизъм, наследяване и времеви фактор в агрегат осигуряват динамиката на първия, т.е. обектът може не само да се променя с времето, но и да генерира обекти, които не са предоставени от разработчика, генерирани от изпълнението на задачата в процеса, проектирана от клиента.
Реален полиморфизъм на ООП, пример
Сложността на задачите, които са мощни ООП, не е сравнима с тази на класическия правописпрограми. Разбира се, решаването на всеки проблем е винаги на разположение по обичайния начин, но въпросът колко ще струва време и усилия често прави резултата безполезен. Не толкова отдавна е разработена библиотека PHPOffice /PHPWord, но за да използва своите възможности, почти винаги трябва да създава своя собствена система от обекти. Например един обикновен * .docx файл:
е zip архив на много Office Open XML файлове и папки (OpenXML, OOXML). Всеки файл е написан в XML тагове и при добавяне, модифициране и изтриване на букви, думи, таблици, списъци и др. елементите на съдържанието на файловете започват да представляват поредица от тагове, които не винаги съдържат пълни елементи, често един елемент е написан от набор от тагове. Ако изпратите този файл като поредица от тагове, ще се появи интересна картина:
Лесно е да се види, че първият и единственият параграф на документа са представени от множество етикети. Що се отнася до таблицата и таблицата, вградена в нея, тогава обемът на описанието на всички елементи не е податлив на възприятие, а достъпен от обектно-ориентирано приложение. В действителност, картината е зелена - това е тест за изходен тест, жълто - параметрите и вида на етикета, бежово - съдържанието. Създадените обекти са фокусирани върху машинната обработка. Само операциите по отваряне на документ, неговото форматиране и запис са достъпни за лицето. Решението е просто и практично, но изпълнението се фокусира повече върху компютъра, отколкото върху човека, причините за размера на изпълними функционални и сложни взаимовръзки между обектите.
Състояние на областта на ООП
Разработване на системи за управление на обекти, технологииконфигуриране и управление на сървъри, опитът в разработването на динамични сайтове, направени обектно-ориентирано програмиране достъпни за всеки. Проблемът е как да промените мисленето си и да свикнете с мисленето на ниво обект, а не в контекста на последователно изпълним код. Обикновено преходът от класическото програмиране към обектно-ориентираното отнема два до три месеца, но цената се изплаща прекомерно. Потенциалът на съвременните езици за програмиране, предимно PHP и javascript, ще задоволи и най-взискателния разработчик. Съвременните ООП - полиморфизъм, наследяване и способност за формиране на свойства на обекти - удобен и практичен, езиков синтаксис и помощни инструменти осигуряват комфорт в работата и кодовата ефективност.
Перспективи на обективната идея
Колко дълго ще продължи класическото програмиране и как ще се развие ООП - трудно е да се каже. Очевидно разработчиците на инструменти не планират да разглеждат контекста на потребителя (потребител, клиент). Инструментариум на ООП - полиморфизъм, имитация, капсулиране и абстракция - са ориентирани към разработчика. Съвременните информационни системи и уеб ресурси се стремят да отразяват реалната действителност, осигуряват функционирането на реални обекти и създават среда за тяхното функциониране, толкова проста, че ще бъде достъпна за потребителя, далеч от програмирането, напълно потопена в сферата на компетентност.
