Инкапсулација је паковање података и функција у једну компоненту. Инкапсулација, полиморфизам, наслеђивање: особине

У касним 1980-има, ништа се није догодило у програмирању. Било је много језика, доста контроверзи и ту је био Турбо Пасцал 5.5, ау пакету његове испоруке било је неких чудних фајлова и неких не тако уобичајених конструкција у синтакси.

Могуће је да објектно оријентисано програмирање свој изглед појави непознатом уметнику, а можда и неколицини, али идеја комбиновања кода и података у тим временима није имала посебно велику вредност. То је било лабаво и индиректно повезано са појмом "енкапсулација".

Структуре, функције и процедуре

Већ у првим верзијама програмских језика, чак и прије појаве првих база података, постало је потпуно јасно да ово није број или низ знакова, већ нешто смислено. Нека то буде варијабла "бројач" у петљи или три варијабле малог слова "презиме", "име", "средње име", али увек има смисла одмах.

"Бројач" је увек после циклуса и ради у њему. "Презиме", "прво име", "средње име" ће бити објављено раме уз раме, и њихово учешће у многим деловима кода биће заједничко. Негде ће се користити самостално, генерално, они ће имати једно значење.

Функције и процедуре првобитно су се појављивале као заједнички делови кода. Њихова употреба првобитно је била намијењена другдје у програму. Њихово појављивање у програму изазвало је понављање блокова истих акција. Понављање у облику функције или процедуре поједностављује локације понављања, смањује количину кода и поједностављује дебаговање.

То није било објектно оријентисано програмирање, већ се од самог почетка еволуције класични стил кодирања бавио компилацијом података, креирањем структура и функционалних дијелова кода.

Разлози за почетак енкапсулације

Инкапсулација у програмирању је почела много прије појављивања ООП-а. Било је то у дубинама класичног стила, значило је функционално програмирање, структурно и било који други који је тражио пут у будућност.

Сваки преводилац и тумач језика марљиво је узео све ново у својој синтакси.

Информација никада није била статична, само је програмирање још увијек задовољно формалном верзијом. Али, чак и ако су строго формализовани, информација обезбеђује рад кода који је увек повезан са њим. Информације никада не могу бити статичне.

Највише тривијалан пример енкапсулације, који је сачуван већ дуже време и релевантан је до данас. Три варијабле "презиме", "прво име", "средње име", где год да су, увек захтевају функције додавања, модификације, брисања. Штавише, ове варијабле пружају масу одређених људи, то јест, много случајева:

• Иванов, Иван, Иванович;
• Петрова, Ирина, Васильевна;
• Кукусхкина, Полина, Григориевна;
• ... и апстрактна класа ...
• "презиме", "име", "средње име";
• ... и три вечне функције ...
• адд;
• промена;
• то ремове.

Постоји велика разноликост оваквих конструкција на било ком нивоу (адресе, позиције, кадрови, план производње). А сложеност имплементације другачијег дизајна ће бити невероватно дуга.

Животни век инстанце енкапсулације

Инкапсулација је податак и код.

• Ријеч је енкапсулација.
• Латинска верзија - у капсули.

Реч "капсула" је оно што значи. Чињеница да су многи језици и програмери мислили о њој (јавном, заштићеном, приватном) је засебна тема и има релативну или примењену везу са значењем енкапсулације.

Све у свему, инстанца је само опција (отисак, тренутак) података, и те три методе живе заувијек. Код као филтер информација "осигурава" живот инстанци, јер је један за све, и успут, за сада :

• код је "стални";
• означава најједноставнију непроменљиву акцију.

Али друга инстанца може "избацити" фокус.

Ако се пример додели листи запослених у компанији, онда ће директор и рачуновођа имати посебно значење у сету примерака. Остатак може остати у уобичајеном "облику". Директор и рачуновођа могу имати своје властите кодове, односно своје функције.

То значи да живот инстанце не одређује увек функционалност три чаробне речи:

• адд;
• промена;
• то ремове.

Ако се пример односи на први лет у свемир, онда ће десетак кандидата за прве космонауте имати пуно специјалне функционалности, стотињак људи (примерака) ће их посматрати на посебан начин, биће много више опција за специјалисте који ће имати много специјалних. функције.

Старт ООП

"Неопходно је да нешто хитно променимо", мислили су бројни програмери, и као добар пример предложили су рад са објектима на Турбо Пасцал 6.0 Профессионал. Ово није идеална понуда, већ врло квалитетан, једноставан и ефикасан.

Под претпоставком да је "енкапсулација, полиморфизам, наслеђе" основа објекта, добијамо добар почетак. Полиморфизам даје потребну динамику, јер инстанце могу имати различиту функционалност. Она се мора некако "легитимисати" у објекту. Наслеђивање омогућава да се одражава хомогеност објекта, да се изгради генеалошко стабло формализованих информација.

Звучи тешко. Под претпоставком да је енкапсулација података једноставна комбинација података и кода, све постаје веома једноставно и појављује се велики концепт.

Објект је податак и код. Једна инстанца објекта је само податак коме његов код има приступ. Може бити пуно инстанци, али код за њих је увијек исти и није везан за свакога, али је доступан свима.

Када инстанца објекта захтева посебну пажњу на себе, појављује се други објекат, који ће имати побољшану функционалност, тј. Наслеђује све што је било у оригиналном објекту, али додаје нешто своје.

Свијет се обогаћује инстанцама другог објекта, који такођер имају нове потребе. Нова функционалност и нови објект.

Али не може сваки нови објект имати потомке. За неке више нису потребни. Као резултат такве конструкције добија се разграната слика објеката, али у стварности она даје живот маси узорака који су међусобно повезани педигреом и функционалним везама.

Идеална варијанта имплементације задатака у ООП стилу је када се енкапсулација, полиморфизам, наслеђе тако квалитетно промишљају да код у потпуности недостаје у програму. Предмети сами обављају своје функције, користе само свој код, граде међусобне односе.

ООП живот

У стварности, све изгледа другачије. Инкапсулација је добра и не можете се овде свађати. Али, да би се исправно изградила слика објеката, размислила о функционалности сваког од њих, предвидети како ће се одређени узорци понашати и шта се може очекивати од података није лако. Било је потребно поједноставити ситуацију, а ПЛО је кренуо путем аутоматизације рада развојног инжењера, умјесто да рјешава стварне проблеме.

Са становишта брзине стицања искуства, ово је ефективна идеја, на крају крајева, зашто би се ООП примењивао на аутоматизацију рачуноводственог рада, када се може додати менију на ХТМЛ страници?

Све је врло једноставно: постоји елемент менија, постоје његове опције. Можете позвати корисника да изабере опције менија (вертикално, хоризонтално, падајуће), можете дати дугмад у облику (округли, квадратни, заобљени, итд.).

Мало је људи заинтересовано за рад и живот инвеститора. Свакоме је потребно рачуноводство, производња, обука, јер је потребно обављати стварне задатке. Дакле, потребно је повећати број колектива, али онда ће систем објеката имплементирати различити стручњаци и они могу наносити штету једни другима.

На много начина, ово је ставило ПЛО на производне трачнице. Више није било сумње: инкапсулација, наслеђе је добар начин, али како заштитити објекте од спољашње интерференције, како споља тако и дуж линије? Не мора нужно бити хакер. Случајно проузрокује штету промјеном података претка, други програмер може.

Модерно програмирање је доста програмера у многим удаљеним канцеларијама. Као и пчеле, модерни програмери граде једну заједничку структуру објеката. Сваки објекат треба да буде изграђен у складу са општим правилима, а они подаци и методе за које је одговоран један програмер не би требало да буду доступни другима. Када неком треба нешто је друга тема. Према основном принципу, свако свој посао обавља на свом сајту.

Инкапсулација је добра, али ...

ПХПВорд је моћан производ, добро направљен и обећавајући. Одличан систем објеката, осмишљен и рад.

Испод је почетак описа унутрашњег објекта овог производа. Једна једноставна апстракција ћелије стола из генерално празне апстракције - нека врста контејнера. И то није све опис.

Нема потребе за роњењем у дивљину да би разумели. Употреба бројних коментара овде не даје јасноћу, а речи заштићене, приватне и јавне кажу, пре свега, да је програмер треће стране, који користи ову библиотеку, променио приватно у јавно на правом месту (погледајте коментар: "сц 06/19/2016 био привате

Ово је чињеница грешке у коду, која је, када се примени, програмер био принуђен да исправи, и зато је морао нешто да промени.

Може се претпоставити да је у фази развоја било неопходно ограничити приступ овим или другим објектима, али овдје је још једна ствар важна. Постоји живот случајева, постоји живот објеката, али већ постоји нови живот - шта се дешава са системом објеката у његовој примени.

Живот у развоју и животу у апликацији. Карактеристична карактеристика модерног програмирања је круто порицање континуитета. Ако је раније програмер гарантовао да ће свака нова верзија допунити и побољшати претходну, онда је данас свака нова верзија објекта, језика, програмског окружења фундаментално или барем фундаментално различита од претходне.

Чак и услови хостинга на хостинг могу да се промене тако да морате да поновите код. Често је то веома тешко.

Добра наследност, добар принос

Нико није имун на грешке. Свако ново пословање захтева знање. ПХПВорд је добра библиотека и само се морате навикнути на њу. Многи професионалци су провели доста времена. Програмер који се окупио да га користи треба да посвети довољно времена за проучавање структуре Ворд датотеке. Ово није тајна.

ПХПВорд објектни систем ће постати транспарентан и приступачан. Даје се онаквим какав јесте, али ако постоји жеља да се иде даље, јер је тренутна функционалност недовољна. Добра идеја. Онда је ово још један систем објеката, и боље је да иде даље.

Није тако лоша идеја тврдог порицања континуитета: она подстиче развој знања. Објекти које је направио један тим програмера су њихове мисли о томе како ријешити проблем, како представити његову функционалност.

Разумијевање овог рјешења од стране друге развојне компаније је трансформација искуства. Ако замислимо да је ово само прототип потребног система објеката, зашто га онда не би наслиједили? Добра наследност - карактеристика природне интелигенције, ослања се на нешто адекватно са стране програмирања - то је из области будућности, иако најближе.

Исправна енкапсулација

Инкапсулација није комбинација података и кода. Ово је комбинација онога што је доступно и онога што је пожељно. Ако не размишљате о подацима и алгоритмима, већ перципирате реалност и изводите адекватну енкапсулацију, наслеђујући ову акцију од девелопера до девелопера, онда је то вероватно: појава система објеката који се крећу и развијају се још увек могу.