Як пояснити концепції об’єктно-орієнтованого програмування 6-річному віку

Ви помічали, як однакові запитання про кліше завжди задають на співбесіді - знову і знову?

Я впевнений, ти знаєш, що я маю на увазі.

Наприклад:

Де ви бачите себе через п’ять років?

або, що ще гірше:

Що ви вважаєте своєю найбільшою слабкістю?

Тьфу ... дайте мені відпочити. Відповідь на це питання я вважаю великою слабкістю! У будь-якому випадку, не моя думка.

Наскільки тривіальними можуть бути такі питання, вони важливі, оскільки дають підказки про вас. Ваш поточний стан душі, ваше ставлення, ваша перспектива.

Відповідаючи, ви повинні бути обережними, оскільки можете виявити те, про що згодом шкодуєте.

Сьогодні я хочу поговорити про подібний тип питань у світі програмування:

Які основні принципи об’єктно-орієнтованого програмування?

Я був з обох сторін цього питання. Це одна з тем, яку так часто задають, що ви не можете дозволити собі цього не знати.

На це зазвичай повинні відповісти молодші та початкові розробники. Оскільки інтерв’юер це простий спосіб розповісти три речі:

  1. Чи готувався кандидат до цього співбесіди?

    Бонусні бали, якщо ви одразу почуєте відповідь - це свідчить про серйозний підхід.

  2. Чи минув кандидат після етапу навчання?

    Розуміння принципів об’єктно-орієнтованого програмування (ООП) показує, що ви вийшли за рамки копіювання та вставлення з навчальних посібників - ви вже бачите речі з вищої точки зору.

  3. Розуміння кандидата глибоке чи неглибоке?

    Рівень компетентності з цього питання часто дорівнює рівню компетентності з більшості інших предметів . Довірся мені.

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

Ці слова можуть здатися страшними для молодшого розробника. А складні надмірно довгі пояснення у Вікіпедії часом подвоюють плутанину.

Ось чому я хочу дати просте, коротке і чітке пояснення кожному з цих понять. Це може звучати як щось, що ви пояснюєте дитині, але я насправді хотів би почути ці відповіді, коли буду проводити співбесіду.

Капсуляція

Скажімо, у нас є програма. У ньому є кілька логічно різних об'єктів, які взаємодіють між собою - згідно з правилами, визначеними в програмі.

Інкапсуляція досягається, коли кожен об’єкт зберігає свій стан приватним , всередині класу. Інші об’єкти не мають прямого доступу до цього стану. Натомість вони можуть викликати лише список публічних функцій - званих методів.

Отже, об’єкт управляє власним станом за допомогою методів - і жоден інший клас не може торкнутися його, якщо це явно не дозволено. Якщо ви хочете спілкуватися з об'єктом, вам слід скористатися наведеними методами. Але (за замовчуванням) ви не можете змінити стан.

Скажімо, ми будуємо крихітну гру Sims. Є люди, а є кішка. Вони спілкуються між собою. Ми хочемо застосувати інкапсуляцію, тому ми інкапсулюємо всю логіку "котів" в aCatклас. Це може виглядати так:

Тут "стан" кота - це приватні змінніmood , hungryі energy. Він також має приватний метод meow(). Він може зателефонувати йому, коли захоче, інші класи не можуть сказати кішці, коли потрібно нявкати.

Що вони можуть зробити, це визначено загальнодоступними методамиsleep() , play()і feed(). Кожен з них якось модифікує внутрішній стан і може викликати його meow(). Таким чином, здійснюється зв'язок між приватною державою та державними методами.

Це інкапсуляція.

Абстракція

Абстракцію можна сприймати як природне продовження інкапсуляції.

В об'єктно-орієнтованому дизайні програми часто надзвичайно великі. І окремі предмети багато спілкуються між собою. Тож підтримувати таку велику кодову базу роками - зі змінами на цьому шляху - важко.

Абстракція - це концепція, спрямована на полегшення цієї проблеми.

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

Цей механізм повинен приховувати внутрішні деталі реалізації. Він повинен розкривати лише операції, що стосуються інших об'єктів.

Подумайте - кавоварка. Він робить багато речей і видає химерні звуки під капотом. Але все, що вам потрібно зробити, - це покласти каву і натиснути кнопку.

Бажано, щоб цей механізм повинен бути простим у використанні і рідко повинен змінюватися з часом. Подумайте про це як про невеликий набір публічних методів, які може назвати будь-який інший клас, не знаючи, як вони працюють.

Ще один реальний приклад абстракції?

Подумайте, як ви користуєтеся телефоном:

Ви взаємодієте з телефоном, використовуючи лише кілька кнопок. Що відбувається під капотом? Вам не потрібно знати - деталі реалізації приховані. Вам потрібно знати лише короткий набір дій.

Зміни впровадження - наприклад, оновлення програмного забезпечення - рідко впливають на абстракцію, яку ви використовуєте.

Спадщина

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

Але чи знаєте ви, що є ще однією поширеною проблемою в дизайні ООП?

Предмети часто дуже схожі. Вони поділяють спільну логіку. Але вони не зовсім однакові. Тьфу ...

Отже, як нам використати загальну логіку та виділити унікальну логіку в окремий клас? Одним із способів досягти цього є спадкування.

Це означає, що ви створюєте (дочірній) клас, виводячи інший (батьківський) клас. Таким чином, ми формуємо ієрархію.

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

Наприклад:

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

Таким чином, кожен клас додає лише те, що для нього потрібно, одночасно використовуючи загальну логіку з батьківськими класами.

Поліморфізм

Ми дійшли до найскладнішого слова! Поліморфізм по-грецьки означає "багато фігур".

Отже, ми вже знаємо силу успадкування і із задоволенням ним користуємось. Але виникає ця проблема.

Скажімо, у нас є батьківський клас і кілька дочірніх класів, які успадковуються від нього. Іноді ми хочемо використовувати колекцію - наприклад, список -, що містить поєднання всіх цих класів. Або у нас є метод, реалізований для батьківського класу - але ми хотіли б використовувати його і для дітей.

Це можна вирішити, використовуючи поліморфізм.

Простіше кажучи, поліморфізм дає можливість використовувати клас точно так само, як його батько, тому не виникає плутанини із змішуванням типів.Але кожен дитячий клас дотримується власних методів, якими вони є.

Зазвичай це відбувається шляхом визначення (батьківського) інтерфейсу для повторного використання. У ній викладено купу поширених методів. Потім кожен дочірній клас реалізує власну версію цих методів.

Кожного разу, коли колекція (наприклад, список) або метод очікує екземпляр батьківського (де описані загальні методи), мова бере на себе оцінку правильної реалізації загального методу - незалежно від того, яку дочірню дитину передано.

Погляньте на ескіз реалізації геометричних фігур. Вони повторно використовують загальний інтерфейс для обчислення площі поверхні та периметра:

Маючи ці три цифри наслідуючи батьків Figure Interfaceдозволяє створювати список змішаних triangles, circlesі rectangles. І ставитися до них як до однотипних об’єктів.

Потім, якщо цей список намагається обчислити поверхню для елемента, буде знайдено та виконано правильний метод. Якщо елементом є трикутник, трикутникCalculateSurface()це називається. Якщо це коло - то круг cirlceCalculateSurface()це називається. І так далі.

Якщо у вас є функція, яка працює з фігурою, використовуючи її параметр, вам не потрібно визначати її тричі - один раз для трикутника, кола та прямокутника.

Ви можете визначити це один раз і прийняти a Figureяк аргумент. Передаєте ви трикутник, коло чи прямокутник - поки вони реалізують CalculateParamter(), їх тип не має значення.

Сподіваюся, це допомогло. Ці безпосередньо ці самі пояснення ви можете використовувати безпосередньо на співбесіді.

Якщо вам щось важко зрозуміти - не соромтеся запитувати в коментарях нижче.

Що далі?

Бути готовим відповісти на одне з класичних запитань інтерв’ю - це чудово - але іноді вас ніколи не викликають на співбесіду.

Далі я зупинюсь на тому, що працедавці хочуть бачити у молодшого розробника та як виділитися серед натовпу при пошуку роботи.

Залишайтеся з нами.