Как да обясним обектно-ориентирани концепции за програмиране на 6-годишно дете

Забелязали ли сте как едни и същи клише въпроси винаги се задават на интервюта за работа - отново и отново?

Сигурен съм, че знаете какво имам предвид.

Например:

Къде се виждате след пет години?

или, още по-лошо:

Какво смятате за най-голямата си слабост?

Ъъъ ... дайте ми почивка. Считам отговора на този въпрос за голяма слабост! Както и да е, не моята точка.

Колкото и тривиални да са въпроси като тези, те са важни, защото дават улики за вас. Вашето текущо състояние на ума, вашето отношение, вашата перспектива.

Когато отговаряте, трябва да бъдете внимателни, тъй като може да разкриете нещо, за което по-късно съжалявате.

Днес искам да говоря за подобен тип въпроси в света на програмирането:

Какви са основните принципи на обектно-ориентираното програмиране?

Бях от двете страни на този въпрос. Това е една от онези теми, които се задават толкова често, че не можете да си позволите да не знаете.

Младите и началните разработчици обикновено трябва да отговорят. Защото интервюиращият е лесен начин да разкаже три неща:

  1. Подготви ли се кандидатът за това интервю?

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

  2. Преминал ли е кандидатът фазата на урока?

    Разбирането на принципите на обектно-ориентираното програмиране (ООП) показва, че сте надхвърлили копирането и поставянето от уроци - вече виждате нещата от по-висока перспектива.

  3. Дълбоко или плитко е разбирането на кандидата?

    Нивото на компетентност по този въпрос често се равнява на нивото на компетентност по повечето други предмети . Вярвай ми.

Четирите принципа на обектно-ориентираното програмиране са капсулиране , абстракция , наследяване ,и полиморфизъм .

Тези думи може да звучат страшно за младши разработчик. А сложните, прекалено дълги обяснения в Уикипедия понякога удвояват объркването.

Ето защо искам да дам просто, кратко и ясно обяснение за всяка от тези концепции. Може да звучи като нещо, което обяснявате на дете, но всъщност бих се радвал да чуя тези отговори, когато правя интервю.

Капсулиране

Кажете, че имаме програма. Той има няколко логически различни обекта, които комуникират помежду си - съгласно правилата, дефинирани в програмата.

Капсулирането се постига, когато всеки обект държи състоянието си частно в клас. Други обекти нямат пряк достъп до това състояние. Вместо това те могат да извикат само списък с публични функции - наречени методи.

И така, обектът управлява собственото си състояние чрез методи - и никой друг клас не може да го докосне, освен ако не е изрично разрешено. Ако искате да комуникирате с обекта, трябва да използвате предоставените методи. Но (по подразбиране) не можете да промените състоянието.

Да приемем, че изграждаме малка игра на Sims. Има хора и има котка. Те общуват помежду си. Искаме да приложим капсулиране, така че капсулираме цялата „котешка“ логика в aCatклас. Може да изглежда така:

Тук "състоянието" на котката е на частни променливиmood , hungryи energy. Той също има частен метод meow(). Може да го извика, когато пожелае, другите класове не могат да казват на котката кога да мяука.

Какво могат да направят, е дефиниран в публични методиsleep() , play()и feed(). Всеки от тях модифицира по някакъв начин вътрешното състояние и може да се позове meow(). По този начин се прави обвързването между частните държавни и публични методи.

Това е капсулиране.

Абстракция

Абстракцията може да се разглежда като естествено продължение на капсулирането.

При обектно-ориентирания дизайн програмите често са изключително големи. И отделните обекти комуникират много помежду си. Така че поддържането на голяма кодова база като тази от години - с промени по пътя - е трудно.

Абстракцията е концепция, целяща да облекчи този проблем.

Прилагането на абстракция означава, че всеки обект трябва да излага само механизъм на високо ниво за неговото използване.

Този механизъм трябва да скрие вътрешни подробности за изпълнението. Той трябва да разкрива само операции, свързани с останалите обекти.

Помислете - кафе машина. Той прави много неща и издава странни звуци под капака. Но всичко, което трябва да направите, е да сложите кафе и да натиснете бутон.

За предпочитане е този механизъм да е лесен за използване и рядко да се променя с течение на времето. Мислете за това като за малък набор от публични методи, които всеки друг клас може да нарече, без да „знае“ как работят.

Друг реален пример за абстракция?

Помислете как използвате телефона си:

Взаимодействате с телефона си, като използвате само няколко бутона. Какво става под предния капак? Не е нужно да знаете - подробностите за изпълнението са скрити. Трябва да знаете само кратък набор от действия.

Промените в изпълнението - например актуализация на софтуера - рядко засягат абстракцията, която използвате.

Наследяване

Добре, видяхме как капсулирането и абстракцията могат да ни помогнат да развием и поддържаме голяма кодова база.

Но знаете ли какъв е друг често срещан проблем в дизайна на ООП?

Обектите често са много сходни. Те споделят обща логика. Но те не са напълно еднакви. Ъъъ ...

И така, как да използваме повторно общата логика и да извлечем уникалната логика в отделен клас? Един от начините да се постигне това е наследяването.

Това означава, че създавате (дъщерен) клас, като произвеждате от друг (родителски) клас. По този начин ние формираме йерархия.

Детският клас използва повторно всички полета и методи на родителския клас (обща част) и може да реализира свои собствени (уникална част).

Например:

Ако нашата програма трябва да управлява държавни и частни учители, но също така и други хора като ученици, можем да приложим тази йерархия на класовете.

По този начин всеки клас добавя само това, което е необходимо за него, докато използва повторно общата логика с родителските класове.

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

Стигнахме до най-сложната дума! Полиморфизмът означава „много форми“ на гръцки.

Така че вече знаем силата на наследяването и с радост я използваме. Но идва този проблем.

Да предположим, че имаме родителски клас и няколко дъщерни класа, които наследяват от него. Понякога искаме да използваме колекция - например списък, която съдържа комбинация от всички тези класове. Или имаме метод, реализиран за родителския клас - но бихме искали да го използваме и за децата.

Това може да бъде решено чрез използване на полиморфизъм.

Просто казано, полиморфизмът дава начин да се използва клас точно като неговия родител, така че няма объркване с типовете смесване.Но всеки клас от деца запазва свои собствени методи, каквито са.

Това обикновено се случва чрез дефиниране на (родителски) интерфейс, който да се използва повторно. Той очертава куп често срещани методи. След това всеки клас-дете изпълнява своя собствена версия на тези методи.

Всеки път, когато колекция (като списък) или метод очаква екземпляр на родителя (където са очертани общи методи), езикът се грижи за оценка на правилното изпълнение на общия метод - независимо кое дете е предадено.

Разгледайте скица на изпълнението на геометрични фигури. Те използват повторно общ интерфейс за изчисляване на повърхността и периметъра:

Като тези три фигури наследява родителя Figure Interfaceви позволява да създадете списък на смесени triangles, circlesи rectangles. И се отнасяйте към тях като към еднотипни предмети.

След това, ако този списък се опитва да изчисли повърхността на елемент, се намира и изпълнява правилният метод. Ако елементът е триъгълник, триъгълникCalculateSurface()е наречен. Ако е кръг - тогава на cirlceCalculateSurface()е наречен. И така нататък.

Ако имате функция, която работи с фигура, използвайки нейния параметър, не е нужно да я дефинирате три пъти - веднъж за триъгълник, кръг и правоъгълник.

Можете да го определите веднъж и да приемете a Figureкато аргумент. Независимо дали подавате триъгълник, кръг или правоъгълник - стига да изпълняват CalculateParamter(), техният тип няма значение.

Надявам се, че това помогна. Можете директно да използвате същите тези обяснения на интервюта за работа.

Ако откриете, че нещо все още е трудно за разбиране - не се колебайте да попитате в коментарите по-долу.

Какво следва?

Подготвеността да отговорите на една от класическите въпроси за интервюта за всички времена е страхотна - но понякога никога не ви призовават за интервю.

След това ще се съсредоточа върху това, което работодателите искат да видят при младши разработчик и как да се открояват от тълпата, когато търсят работа.

Останете на линия.