Како шестогодишњаку објаснити објектно оријентисане концепте програмирања

Да ли сте приметили како се иста питања о клишејима увек постављају на разговорима за посао - изнова и изнова?

Сигуран сам да знате на шта мислим.

На пример:

Где се видите за пет година?

или, још горе:

Шта сматрате својом највећом слабошћу?

Уф ... дај ми предах. Одговор на ово питање сматрам великом слабошћу! Свеједно, није моја поента.

Колико год оваква питања била тривијална, она су важна јер дају назнаке о вама. Ваше тренутно стање ума, ваш став, ваша перспектива.

Када одговарате, будите опрезни јер ћете можда открити нешто због чега ћете касније зажалити.

Данас желим да разговарам о сличној врсти питања у свету програмирања:

Који су главни принципи објектно оријентисаног програмирања?

Био сам на обе стране овог питања. То је једна од оних тема која се толико често пита да не можете себи да допустите да не знате.

На то обично морају одговорити млађи програмери и почетници. Јер је анкетар једноставан начин да каже три ствари:

  1. Да ли се кандидат припремао за овај интервју?

    Бонус поени ако одмах чујете одговор - то показује озбиљан приступ.

  2. Да ли је кандидат прешао фазу подучавања?

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

  3. Да ли је разумевање кандидата дубоко или површно?

    Ниво компетенције по овом питању често је једнак нивоу компетенције за већину осталих предмета . Веруј ми.

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

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

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

Капсулација

Рецимо да имамо програм. Има неколико логички различитих објеката који међусобно комуницирају - према правилима дефинисаним у програму.

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

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

Рецимо да градимо мајушну Симс игру. Постоје људи и постоји мачка. Они међусобно комуницирају. Желимо да применимо енкапсулацију, тако да сву „мачју“ логику капсулирамо уCatкласа. То може изгледати овако:

Овде су „стање“ мачке приватне променљивеmood , hungryи energy. Такође има приватну методу meow(). Може га назвати кад год пожели, док остали разреди не могу рећи мачки када да мијауче.

Шта они могу да ураде је дефинисано у јавним методамаsleep() , play()и feed(). Сваки од њих некако модификује унутрашње стање и може се позивати meow(). Тако је направљено везивање између приватне државне и јавне методе.

Ово је инкапсулација.

Одвајање

Апстракција се може сматрати природним продужетком инкапсулације.

У објектно оријентисаном дизајну, програми су често изузетно велики. И одвојени предмети много комуницирају једни с другима. Стога је тешко одржавати велику базу кода попут ове годинама - уз промене на путу - тешко.

Апстракција је концепт чији је циљ ублажавање овог проблема.

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

Овај механизам треба да сакрије детаље о интерној имплементацији. Требало би да открије само операције релевантне за остале објекте.

Помислите - апарат за кафу. Ради пуно ствари и ствара необичне звукове испод хаубе. Али све што треба да урадите је да ставите кафу и притиснете дугме.

Пожељно је да овај механизам буде једноставан за употребу и да се ретко мења током времена. Схватите то као мали скуп јавних метода које било која друга класа може назвати, а да „не зна“ како раде.

Још један стварни пример апстракције?

Размислите о томе како користите телефон:

Са телефоном комуницирате помоћу само неколико тастера. Шта се дешава испод хаубе? Не морате знати - детаљи имплементације су скривени. Морате знати само кратак скуп акција.

Промене у примени - на пример, ажурирање софтвера - ретко утичу на апстракцију коју користите.

Наслеђивање

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

Али да ли знате шта је још један уобичајени проблем у дизајнирању ООП-а?

Предмети су често врло слични. Они деле заједничку логику. Али нису потпуно исти. Уф…

Па како да поново употребимо уобичајену логику и издвојимо јединствену логику у засебну класу? Један од начина да се то постигне је наследство.

То значи да креирате (подређену) класу изводећи из друге (родитељске) класе. На овај начин формирамо хијерархију.

Подређена класа поново користи сва поља и методе родитељске класе (заједнички део) и може да примени своја (јединствени део).

На пример:

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

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

Полиморфизам

Дошли смо до најсложеније речи! Полиморфизам на грчком значи „много облика“.

Дакле, ми већ знамо моћ наследства и радо је користимо. Али долази овај проблем.

Рецимо да имамо родитељски разред и неколико подређених разреда који га наслеђују. Понекад желимо да користимо колекцију - на пример листу - која садржи комбинацију свих ових класа. Или имамо метод примењен за родитељски разред - али волели бисмо да га користимо и за децу.

Ово се може решити применом полиморфизма.

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

То се обично дешава дефинисањем (надређеног) интерфејса који ће се поново користити. У њему се наводи гомила уобичајених метода. Затим свака подређена класа примењује своју верзију ових метода.

Сваки пут када колекција (као што је листа) или метода очекује примерак родитеља (где су истакнуте уобичајене методе), језик се стара о процени исправне примене уобичајене методе - без обзира на то које дете је прослеђено.

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

Имајући ове три фигуре наследе родитеља Figure Interfaceомогућава да направите листу мешовити triangles, circlesи rectangles. И понашајте се према њима као према истој врсти предмета.

Затим, ако ова листа покушава израчунати површину елемента, проналази се и извршава исправна метода. Ако је елемент троугао, троугаоCalculateSurface()се зове. Ако је то круг - онда кругCalculateSurface()се зове. И тако даље.

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

Можете га једном дефинисати и прихватити а Figureкао аргумент. Без обзира да ли пролазите кроз троугао, круг или правоугаоник - све док их имплементирају CalculateParamter(), њихов тип није важан.

Надам се да је ово помогло. Ова потпуно иста објашњења можете директно користити на разговорима за посао.

Ако вам је и даље тешко нешто за разумевање - не устручавајте се да питате у коментарима испод.

Шта је следеће?

Спремност да одговорите на класику свих времена за интервју је сјајна - али понекад вас никад не позову на интервју.

Даље, фокусираћу се на оно што послодавци желе да виде код млађег програмера и на то како да се истакну од гомиле када траже посао.

Будите у току.