Програмирането е процес на разработване на решения за "живи", динамични задачи под формата на твърди структури на код, данни, функции и алгоритми. Процедурата за формиране на строг синтаксис с несигурна семантика. Истинската задача е добре известният голям проблем в смисъла на алгоритмизацията: за да се постигне желаното решение, задачата трябва да бъде поставена в точни синтактични конструкции.
Ниво и квалификация
Обективно и фактът, че предприемачът не настоява, а клиентът не изисква реално решение на реалните проблеми. И двете страни са свикнали да се ограничават с наличните инструменти и навици. Формите на полиморфизъм на ООП, идеята за инкапсулиране на кодове и наследяването на свойствата (методите) са в областта на програмирането, но не и в областта на решаване на проблема. Пример за това е библиотеката PHPOffice /PHPWord. За да го използвате изисква квалификация на разработчика, трябва да създадете своя собствена система от обекти, но сегашното ниво на клиента (изисквания на клиента) - тривиален състав, който програмистът се припокрива с неговото развитие (в противен случай не отговарят на изискванията). Ситуация като тази:
Пълен анализ на документа, неговото събиране в правилния формат, работа с таблици на всяко ниво на гнездене, сливане и разделяне на клетки, печат във всяка посока и т.н.
Полиморфизъм и ООП По-добра дефиниция за полиморфизма не е да се мисли как да се разчита на историята на развитието на идеята за обектно-ориентирано програмиране, толкова популярно в наши дни, толкова често използвано, но нереализирано в същността си до ден днешен. Всеки автор има собствена концепция за началото и характера на ООП. За всеки внимателен читател тази концепция е надеждна и обективна. Но до ден днешен всички приемат като безусловна аксиома само три позиции:
Популярни определения на полиморфизма
Същност: разработчик - клиент
Прозорци, бутони и други предмети
Обект и система от обекти: алгоритъм
В идеалния случай, това е просто компютър, който може да разбере какво иска клиентът и да прави това, което той иска. Как ще изглежда: местна програма или уебсайт, достъпни чрез браузър, специална програма за разпределена обработка на информация, информационна система за клиента - няма значение. От съществено значение е между задачата и компютъра да няма ненужни връзки, а първо да е разбираемо и да се реши второто. За постигането на тази цел компютърът и клиентът трябва да бъдат свързани с една система от обекти, а съдържанието, структурата и съдържанието на всеки обект се определя от клиента, както и методите и свойствата на обектите, реализирани от програмиста. Идеално, когато работата на клиента за създаване на обектна система, от която се нуждае, и работата по внедряването на методите и свойствата на тези обекти се разпределят във времето. Колкото по-нататъшното изпълнение на системните обекти (програмиста) от съдържанието му (клиент) ще се защитава, толкова по-добър процес. Нищо не пречи на клиента и програмиста да взаимодействат в процеса на решаване на проблема, но е важно да има ясно разделение на семантиката. Всеки трябва да прави свой бизнес, програмистът не е задължен да овладее районаприлагането на задачата, а клиентът не трябва да разбира кода и по-специално страните не трябва да си дават съвети един на друг, тъй като те не се отнасят.
Основни постулати на ООП: капсулиране, наследяване, полиморфизъм във формата, в която те стават обичайни и търсени, водят до забележими подобрения в качеството и надеждността на кода, значително ускоряват работата на програмиста и имат много други положителни качества.
Традиционно и обектно програмиране
Но те също са в движение: класическото програмиране не е по-лошо от позициите им, а много обектно-ориентирани идеи се изпълняват от класическия код. Въпреки това, идеите на ООП и рекурсия доведоха до адекватно влияние върху синтаксиса на класическите синтактични оператори, върху логиката на конструиране на редовен код, който няма нищо общо с обектно-ориентирания стил на писане и мислене. Списъците и опашките се промениха, появи се концепцията за първия и последния елемент на масива, имаше цикли "за всеки", а примерните варианти на именуване, използване и изпълнение станаха още по-популярни, отколкото преди. Всъщност самият факт, че променливите губят своя "ясен" човек (видът на променливата може да варира според нуждите, но описанието на променливата изобщо не е необходимо), казва, че класиката всъщност отдавна е обектно ориентирана и признава основните принципи на PLO: капсулиране наследство, полиморфизъм като идеи, които имат значително значение.
Абстракция, като основна концептуална позиция на ООП, независимо от това къде се намира зоната на отговорност (изпълнение)обект - на нивото на първия абстрактен обект или на нивото на конкретен потомък - оставя отворен въпроса: откъде да започнем, от обекта или системата?
Ако основата е да постави обект, то никога няма да се превърне в система, защото системата ще бъде вътре в нея и той ще стане твърдо напълно конкретен старт. Тук, с абстракцията, има проблеми: първоначалният обект точно улавя основния проблем в решението, т.е. той вече не може да се прехвърля на друга задача. Ако в основата на поставянето на системата от обекти, след това на системата от системи. Трудно е да си представим по отношение на конкретна задача, от която да започнем развитието - също е трудно да се разбере. Като цяло, полиморфизмът на ООП с неговите различия по същество, форма на реализация, брой действителни параметри в функциите дава представа за системата, която се намира в началото, като:за възможности за решаване на проблеми (например менюто); за началните условия (прилагане на задачата при различни условия, данни); относно режимите на работа (изпитване, конфигуриране, работа). Но това и други подобни не му дават основание да постави основата за решаване на проблема с една система от обекти. Често е достатъчно да се дефинира един обект.
Най-важните принципи на ООП: полиморфизъм и абстракция - определят приоритетния обект като система от обекти. В спор, който трябва да бъде преди, пиле или яйце, победата тук получава пушач. Няма съмнение, че всичко трябва да започне с абстрактен обект, но не и от система от обекти. ноако вземем предвид фактора на времето и го приложим на нивото на всеки обект, започвайки с първия абстрактен текст, тогава противоречивата мисъл е да поставим решението и обекта в началото, а системата е единствената интелигентна. Ако класическата концепция за програмиране по време на решаването на проблема променя данните, съдържанието на базата данни, файловете за промени и т.н., концепцията за полиморфизъм на ООП, капсулирането и факторът на времето променят съдържанието, структурата и свойствата на обектите на системните обекти, които трябва да бъдат решени. Програмистът в ООП най-малко се интересува от концепцията за файл, база данни, алгоритъм - това е особено, тук програмистът мисли обекти, но обектите съществуват във времето и се променят в хода на желаното.
Така в началото обектът се намира като система от обекти и логиката на тази система - времевата линия: стартирането на задача, формирането на първия обект, въвеждането или събирането на данни, формирането на следващия обект, но нищо не пречи на първия да се противопостави на следващото решение. Всяко ниво на обекти действа като независима система от обекти, т.е. тя е един обект, но в контекста на инициирания процес и времевата стойност е система от обекти по времева скала. За пълното прилагане на ООП, полиморфизъм, наследяване и времеви фактор в агрегат осигуряват динамиката на първия, т.е. обектът може не само да се променя с времето, но и да генерира обекти, които не са предоставени от разработчика, генерирани от изпълнението на задачата в процеса, проектирана от клиента.
Сложността на задачите, които са мощни ООП, не е сравнима с тази на класическия правописпрограми. Разбира се, решаването на всеки проблем е винаги на разположение по обичайния начин, но въпросът колко ще струва време и усилия често прави резултата безполезен. Не толкова отдавна е разработена библиотека PHPOffice /PHPWord, но за да използва своите възможности, почти винаги трябва да създава своя собствена система от обекти. Например един обикновен * .docx файл:
е zip архив на много Office Open XML файлове и папки (OpenXML, OOXML). Всеки файл е написан в XML тагове и при добавяне, модифициране и изтриване на букви, думи, таблици, списъци и др. елементите на съдържанието на файловете започват да представляват поредица от тагове, които не винаги съдържат пълни елементи, често един елемент е написан от набор от тагове. Ако изпратите този файл като поредица от тагове, ще се появи интересна картина:
Основа: обект или система
История на процеса на решаване на проблема
Реален полиморфизъм на ООП, пример
Лесно е да се види, че първият и единственият параграф на документа са представени от множество етикети. Що се отнася до таблицата и таблицата, вградена в нея, тогава обемът на описанието на всички елементи не е податлив на възприятие, а достъпен от обектно-ориентирано приложение. В действителност, картината е зелена - това е тест за изходен тест, жълто - параметрите и вида на етикета, бежово - съдържанието. Създадените обекти са фокусирани върху машинната обработка. Само операциите по отваряне на документ, неговото форматиране и запис са достъпни за лицето. Решението е просто и практично, но изпълнението се фокусира повече върху компютъра, отколкото върху човека, причините за размера на изпълними функционални и сложни взаимовръзки между обектите.
Разработване на системи за управление на обекти, технологииконфигуриране и управление на сървъри, опитът в разработването на динамични сайтове, направени обектно-ориентирано програмиране достъпни за всеки. Проблемът е как да промените мисленето си и да свикнете с мисленето на ниво обект, а не в контекста на последователно изпълним код. Обикновено преходът от класическото програмиране към обектно-ориентираното отнема два до три месеца, но цената се изплаща прекомерно. Потенциалът на съвременните езици за програмиране, предимно PHP и javascript, ще задоволи и най-взискателния разработчик. Съвременните ООП - полиморфизъм, наследяване и способност за формиране на свойства на обекти - удобен и практичен, езиков синтаксис и помощни инструменти осигуряват комфорт в работата и кодовата ефективност.
Колко дълго ще продължи класическото програмиране и как ще се развие ООП - трудно е да се каже. Очевидно разработчиците на инструменти не планират да разглеждат контекста на потребителя (потребител, клиент). Инструментариум на ООП - полиморфизъм, имитация, капсулиране и абстракция - са ориентирани към разработчика. Съвременните информационни системи и уеб ресурси се стремят да отразяват реалната действителност, осигуряват функционирането на реални обекти и създават среда за тяхното функциониране, толкова проста, че ще бъде достъпна за потребителя, далеч от програмирането, напълно потопена в сферата на компетентност.