В края на 80-те години на миналия век нищо фундаментално не се промени в програмирането. Имаше много езици, много спорове и имаше Turbo Pascal 5.5, а при доставката на пакета имаше няколко странни файла и няколко неконвенционални структури в синтаксиса.
Вероятно обектно-ориентираното програмиране се дължи на появата на непознат художник, а може би и на няколко, но особено голяма стойност, идеята за комбиниране на код и данни в онези далечни времена не се носи. С термина "капсулиране" той е свързан слабо и непряко.
Структури, функции и процедури
Още в първите версии на езиците за програмиране, преди да се появят първите бази данни, беше абсолютно ясно, че това не е число, а не низ от символи, а нещо смислено. Нека това е променлива "брояч" в цикъл или три променливи "фамилия", "име", "бащино", но това винаги е незабавно.
"Брояч" винаги се намира след цикъла и работи в него. И "фамилно име", "име", "бащино име" ще бъдат обявени заедно, и тяхното участие в много части на кода ще бъде споделено. Там, където те ще бъдат използвани самостоятелно, като цяло, те ще имат един смисъл. Функциите и процедурите първоначално се появяват като общи части от кода. Първоначално тяхното използване беше предвидено в други места на програмата. Появата им в програмата обуславяше повторението на блоковете от същите действия. Премахването на повторение под формата на функция или процедура опростява мястото на повторение, намалява количеството на кода и опростяваотстраняване на грешки.
Това не беше обектно-ориентирано програмиране, но класическият стил на кодиране от самото начало на своята еволюция се занимаваше с обобщаване на данни, създаване на структури и функционални области на кода.
Причини за започване на капсулиране
Инкапсулирането в програмирането започна много преди ООП. Тя е в дълбините на класическия стил, тя не взема предвид функционалното програмиране, структурното и всичко останало, което се стреми да намери начин за бъдещето. Всеки компилатор и интерпретатор на езика усърдно взимаше всичко ново в своя синтаксис, предлагайки на разработчиците опции за реализация на семантиката. Информацията никога не е била статична, просто програмирането все още е удовлетворено от формализираната версия. Но дори и да е строго формализирана, информацията предоставя работен код, който винаги е свързан с него. Информацията никога не може да бъде статична.
Най-тривиалният пример за капсулиране, който отдавна е запазен и до днес. Три променливи "фамилно име", "име", "бащино", където и да са, винаги изискват функциите на добавяне, редактиране, изтриване. Освен това тези променливи осигуряват маса от конкретни хора, т.е. много копия:
Иванов, Иван, Иванович; Петрова, Ирина Василевна; Кукушкина, Полина, Григориевна; и абстрактен клас "фамилно име", "име", "бащино име"; и три вечни функции; промяна; изтриване.Такива проекти на всяко ниво (адреси, работни места, персонал, производствен план)можеш да се сетиш много. И сложността на изпълнението на друг дизайн ще бъде изключително дълъг.
Време на живот на инкапсулирано копие
Инкапсулирането е данни и код.
Капсулиране на Word. Латинска версия - в капсула.Думата "капсула" е това, което означава. Фактът, че много езици и разработчици са измислили (публично, защитено, лично) - темата е отделна и съдържанието на капсулирането има или относително или приложено отношение. Като цяло инстанцията е просто вариант на (снимки, моменти) от данни и тези три метода живеят вечно. Кодът като информационен филтър "осигурява" живота на инстанциите, защото той е уникален за всички и, между другото, досега:
кодът е "постоянен"; означава най-простия непроменящ се ефект.Но друг случай може да "изхвърли" трика. "Ако даден пример се приписва на персонала на компанията, тогава директорът и счетоводителят ще бъдат от особено значение в комплекта от копия, докато други могат да останат в обичайната форма." Директорът и счетоводителят могат да имат свои собствени кодове, т.е. техните функции. Това означава, че животът на случая не винаги се определя от функционалността на трите магически думи:
add; промяна; изтриване.Ако примерът се приписва на първия човешки полет в космоса, то тогава добра дузина кандидати за първите астронавти ще имат много специална функционалност, добри стотици хора (екземпляри) ще бъдат последвани от тях по специален начин, все още ще има много възможности за професионалисти, които ще бъдат много много специални функции.
Начало на ООП
"Неотложно е нещо да се промени", - смятаха някои разработчици иКато добър пример предложих да се работи с обекти на Turbo Pascal 6.0 Professional. Това не е идеална оферта, но много високо качество е лесно и ефективно.
Поставяйки, че "капсулиране, полиморфизъм, наследство е основата на един обект, получаваме добро начало." Това прави трудно да се покаже хомогенността на обекта, да се изгради генеалогично дърво на формализираната информация и е трудно да се каже, че капсулирането на данни е проста комбинация от данни и кодове, всичко е много просто и има голяма концепция. Индекс на обекта - достъп до кода му имат само данните. Може да има много случаи, но кодът за тях винаги е един и същ и не е свързан с всички, но е достъпен за всеки. обект, който ще има подобрена функционалност, т.е. наследява всичко, което е в оригиналния обект, но добавя свой собствен.
Светът се попълва с копия на втория обект, който също има нови нужди. Нова функционалност и нов обект. Но не всеки нов обект може да има потомци. Някои дори не се нуждаят от тях повече. В резултат на тази конструкция се получава разклоняваща се картина на обекти и в действителност тя дава живот на голям брой копия, свързани помежду си с родословия и функционални съединения. Идеалният начин за постигане на задача в стила на ООП е когаинкапсулиране, полиморфизъм, наследство се разглеждат толкова качествено, че кодът в програмата е напълно отсъстващ. Самите обекти изпълняват своите функции, използват само техния код, изграждат взаимоотношения помежду си.
Живот на ООП
В действителност всичко изглежда много различно. Инкапсулирането е добро и вие не спорите тук. Но за правилно изграждане на картина на обекти, за да се мисли над функционалността на всеки, да се предскаже как някои или други случаи, които могат да се очакват от данните, се държат сами, не е лесно. Трябваше да опростя ситуацията и ООП пое по пътя на автоматизацията на разработчиците, вместо да решава реални проблеми. От гледна точка на скоростта на натрупване на опит - това е ефективна идея, тъй като какво трябва да направи ООП, за да автоматизира счетоводната работа, когато може да бъде добавена към менюто на HTML страница? Много е просто: има елемент от менюто, има и негови варианти. Можете да предложите на потребителя да избере опции в менюто (вертикално, хоризонтално, падащо), можете да дадете на бутоните форма (кръгла, квадратна, закръглена и т.н.).
Малко хора се интересуват от работата и живота на предприемача. Всеки се нуждае от счетоводство, производство и обучение, защото трябва да се направят реални задачи. Така че трябва да увеличите екипите, но след това системата от обекти ще бъде реализирана от различни специалисти и те могат да навредят един на друг. В много отношения тя постави ООП в производствените релси. Вече нямаше съмнение: капсулирането, наследяването е добър начин, но как да се предпазят обектите от намеса на трета страна, както от страна, така и от родословието? Това не е непременно хакер.Случайно повредите, като промените данните на своя прародител, може би друг разработчик. Модерното програмиране е много разработчици, които са в набора от отдалечени офиси. Като пчели, съвременните разработчици изграждат една обща структура от обекти. Всеки обект трябва да бъде изграден в съответствие с общите правила, а данните и методите, за които един отговор от програмист не трябва да бъде достъпен за други. Когато някой се нуждае от нещо - това е друга тема. По основен принцип всеки прави своето нещо в техния район.
Капсулирането е добро, но
PHPWord е мощен, добре направен и обещаващ продукт. Отлична система от обекти, добре обмислени и ефективни. По-долу е началото на описанието на вътрешния обект на този продукт. Една проста абстракция на клетката на таблицата от обикновено празната абстракция - контейнер. И това е далеч от цялото описание.
Не е нужно да се потопите в калта, за да разберете. Използването на много коментари не добавя яснота, а думите защитени, частни и публични като цяло казват, преди всичко, че разработчикът на трета страна, използващ тази библиотека, се е променил на точното място частно на публично (виж коментара: "sc 19062016 са частни)" , Това е грешка в кода, която, когато се прилага, разработчика е принуден да поправя и следователно трябва да промени нещо. Можем да предположим, че на етапа на разработване трябва да ограничите достъпа до определени обекти, но тук е важно да бъде напълно различен. Има живот на екземпляри, има живот на обекти, но има нов живот - какво се случва със системата от обекти в неговото приложение. Живот в дизайна и живота в приложение. характеристикахарактеристика на съвременното програмиране - твърдо отрицание на приемствеността. Ако по-рано разработчикът е осигурил всяка нова версия да допълва и подобрява предишната, днес всяка нова версия на обекта, езика, програмната среда е фундаментално или поне фундаментално различна от предишната. Дори условията за хостинг на хостинг услуга могат да се променят, така че ще трябва да обработите кода. И често е много трудно.
Добро наследство, добър изход
Никакви грешки не са осигурени. И всеки нов бизнес изисква знания. PHPWord е добра библиотека и просто трябва да свикнеш с него. Много специалисти прекараха много време. Разработчикът, който се кани да го приложи, трябва да отделя достатъчно време за изучаване на структурата на Vordovian файла. Това не е тайна. Системата от PHPWord обекти ще бъде прозрачна и достъпна. Дава се такава, каквато е, но ако има желание да се отиде по-далеч, защото сегашното функциониране не е достатъчно. Добра идея. Тогава това е друга система от обекти, и по-добре, ако тя продължава по-далеч. Не е толкова лоша идеята за твърдо отхвърляне на приемствеността: тя стимулира развитието на знанието. Обекти, построени от един екип от разработчици, са техните размисли за това как да решат дадена задача, как да представят нейната функционалност.
Разбирането на това решение от друга компания разработчик е трансформация на опита. Ако си представите, че това е само прототип на желаната система от обекти, защо просто не го наследявате? Доброто наследство - черта на естествената интелигентност, разчита на нещо адекватно от страна на програмирането - това е от полетобъдещето, макар и най-близкото.
Правилно капсулиране
Инкапсулирането изобщо не е комбинация от данни и код. Това е комбинация от достъпни и желани. Ако мислите за данни и алгоритми, но за да възприемате валидността и да приложите адекватно капсулиране, наследяването на това действие от разработчика към доставчика, то тогава е вероятно: появата на системи на движещи се обекти и саморазвиващи се, все още е възможно.
