Як пояснити поняття ООП неспеціалістичній особі?

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

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

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

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

Тоді я попрошу їх забути про машину чи вантажівку і просто попрошу продовжити опис транспортного засобу:

"О, добре рухається"

"У нього є оператор або водій"

тощо ...

Незабаром ми дізнаємося, що таке транспортний засіб, і я сказав, що в ООП ми визначимо транспортний засіб, і заради аргументу скажемо, що він може рухатись і давати йому водій свого роду. Тоді я запитаю, добре, так що ж має Автомобіль?

"Двері"

"Windows"

А потім вантажівка….

"Двері" "вікна" "Ще колеса!"

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

1) Що являє собою транспортний засіб

2) Що являє собою автомобіль

3) Що являє собою вантажівка

4) Що являє собою літак.

Все без жодних технічних даних Ми розділили властивості кожного на потрібні області. Вони розуміють спадщину ("Ага, машина - транспортний засіб, вантажівка - транспортний засіб, але машина - не вантажівка. Це ПРОСТО, так!").

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

Залежно від їхньої освіти та походження, деякі отримують це швидше, ніж інші. Але коли я порівнюю OOP з об'єктами реального життя, більшість людей завжди це отримує. Насправді я знайшов у розмовах з нетехнічними людьми речі, про які ніколи не думав. Транспортні засоби не потребують, наприклад, безпілотників (безпілотники), але чи програміст вважав би оператора транспортного засобу властивістю цього? Я не кажу, що згадувати оператора правильно чи неправильно, але це змушує задуматися про те, що ми моделюємо, і що ми намагаємося досягти, розробляючи програмне забезпечення.

Тепер часткова спеціалізація шаблонів, з іншого боку .... :)

Об’єкти - іменники, методи - дієслова.

Ось деяка версія моєї відповіді в консервах, яку я даю особі, яка не має технічних даних:

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

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

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

Людські істоти часто мають взаємодію з іншими типами "речей", будь то тварини, інші люди, інші живі організми чи неживі предмети. У реальності є такі теми, які часто потребують представлення способу, такі як взаємодія між "речами", категоризація речей тощо. Розглянемо бізнес-процеси, які тривають у нашій організації. Існує дуже складна "бізнес-логіка", яку потрібно представити в програмному забезпеченні, яке використовує наша організація.

Об'єктно-орієнтоване програмування забезпечує спосіб точного представлення цих "реальних понять світу" та "бізнес-логіки".

-> Цього твердження зазвичай достатньо, щоб стримати їх цікавість (або, можливо, набридає їх до сліз), але якщо у них більше запитань, вищезазначене твердження (я вважаю) закладає гідну основу, куди може йти розмова. Я насправді не думаю, що нетехнічна особа надто переймається технічною термінологією, такою як "Абстракція", "Склад", "Поліморфізм" тощо, але якщо вони є, мова, яку я використав у консервованій заяві, дозволяє мені витягувати на його основі приклади.

Я завжди навчався OOP так:

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

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

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

І там у вас є 3 кути об'єктно-орієнтованого програмування. Все інше - просто кодування.

Я просто сказав би їм записатися на курс в ООП, якщо вони дійсно хочуть це зрозуміти.

Я маю на увазі всі ті аналогії, як Car.startEngine (); є, припустимо, чистий реп. Коли я був вперше в OOP багато років тому, я виявив, що вони лише ще більше абстрагують домен.

Замість того, щоб просто пояснювати, що ООП стосується управління складністю процедурних мов, майже 80% авторів книг програмування припускають, що програмісти - це безглузді ідіоти, про яких потрібно говорити простими (див. Тут іронія?)

Так, цілком нормально працювати з поясненнями списків і векторів, тому що саме з цим ми працюємо, а не Car.Engine та PoliceMan.Arrest (якщо ви не ігровий розробник, але знову ж таки, ви все одно повинні мати свою частку колишній).

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

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

Я розповів про цю розмову з дружиною про цю саму річ, у цій відповіді тут: /software/45464/how-to-convince-non-programmer-his-notions-about- комп’ютери - помиляються / 45467 # 45467

EDIT: Питання, на яке я там відповів, було відмінене, тому я знову перекрию свою відповідь.

Сидячи в ресторані з моєю дружиною, вона запитала мене: "Що означає" Орієнтоване "?

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

Тому я схопив пакет з Splenda з контейнера. Я сказав: "Ось предмет. Які його властивості?"

Вона сказала: "Вона прямокутна, вона зроблена з паперу, вона містить розкіш, синя, на ній є друк".

Я взяв пакет із цукром. "Що це спільного з цим?"

Вона сказала: "Прямокутність, папір, що там друк".

Я сказав: "А що з того, що вони обидва містять щось солодке?"

Вона сказала: "Звичайно".

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

Вона сказала: "Звичайно".

Я сказав: "І кожен має властивості, успадковані від абстрактного пакету, а потім варіації того, які є специфічними для його типу речі".

Вона сказала: "Правильно. О! І якби я хотіла зробити, як, наприклад, сахариновий пакет, я взяла б загальний і встановила б деталі про нього для Сахарину, і тоді я б це мала!"

Я сказав: "Бінго: Об'єктно-орієнтоване програмування".

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

Це питання, здається, є кандидатом на закриття, проте ...

Як і більшість речей, OOP насправді дуже просто пояснити на концептуальному рівні. Програмісти моделюють об'єкти; і:

• об'єкти мають стан (поля / члени даних)
• об'єкти мають дії (методи / функції)
• об'єкти будуються один на одного (спадщина)

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

Приклад мобільного телефону:

Уявіть, що ви власник фабрики, хочете описати загальний телефон

• Крок 1. Перерахуйте ці загальні властивості телефонів, наприклад: висоту, вагу, колір тощо
• Крок 2. Перерахуйте ці загальні функції телефону, наприклад: телефонувати, приймати дзвінки, надсилати SMS тощо

Тепер, коли у вас є загальний "план", створіть мені наступні телефони:

Телефон 1:

• Висота-> 102мм

• Вага-> 85г

• Колір-> Рожевий

Телефон 2:

• Висота-> 125мм

• Вага-> 96г

• Колір-> Червоний

Я думаю, що найкращий спосіб пояснити нетехнічному типу про ООП - це пов’язати його з ними.

По суті, OOD і OOP хочуть, щоб ви подумали про систему, яку ви проектуєте та впроваджуєте, як світ взаємодіючих речей.

Тож давайте, заради аргументу (який ніколи не виходить в Інтернеті), скажіть, що ви пояснюєте колектору відмов про OOD & P. Його звуть Боб. Ви раніше ходили з ним до школи 15 років тому, ви натрапили на нього в бар, і ви обоє цікавитесь життям один одного.

"Отже, Джон, ти кажеш, що ти програміст. Мій племінник займається усією цією нісенітницею. Продовжує тривати навколо об'єктно-орієнтованого програмування чи чогось іншого. Про що це?" Зауважте, що Боб - британець із того, як він неправильно орієнтується.

"Ну, Боб", - відповідаєте ви, поводячись зорієнтовано. "Насправді це дуже просто. Ви збираєте сміття, правда? Що, як правило, ви займаєтесь своєю роботою?"

"Ну, я слідкую за фургоном по місту, збираючи сміття і кладучи його в фургон", - запитально відповідає Боб.

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

Боб заснув у своєму пиві. Ти йдеш геть.

Мені подобається приклад автомобіля для пояснення спадщини (я, як правило, використовую тварин, а не транспортні засоби, але це та сама ідея), але для пояснення того, як працює об’єктно-орієнтована програма, я посилаюся на аналогію, яку я одного разу прочитав на веб-сайті Кріса Кроуфорда: програма схожа дійсно ефективна бюрократія. Усі різні об'єкти програми схожі на різні відділи бюрократії; у кожному відділі є власні призначені завдання, вони мають чітко визначені дані (з ким спілкуватися та які форми заповнювати), а інші відділи часто не знають, що багато про те, що відбувається всередині. HR - це як абстрактна фабрика, IT - сингл тощо.

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

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

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

Ми все ще намагаємося розібратися, як завантажити наші думки та бажання на протокол і спільну мову, і я, на думку, історики одного дня будуть зачаровані його витонченою грубістю - як ми бачимо ієрогліфи. Це зовсім не "розумно" - це просто підкреслює, як ми не можемо легко пояснити, як ми вирішуємо чи розуміємо навіть найпростіші речі. Обчислення все ще на рівні "собака - собака, тому що це не кішка" - еволюція думки - це тисячоліття за рівнем навіть основної розмовної мови.

Є два види чарівників. Там хлопець, який робить конкретні речі з магічними словами. У нього є слово для виклику вогню. У нього є слово про те, щоб заморожена курка з’явилася з повітря. І ще одне слово для створення горщика сили (я віддаю перевагу своїй силі зелений, сяючий і напівпрозорий), наповнений грізною добротою. При правильному застосуванні своїх слів він може виробляти смажену курку.

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

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

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

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