Как объяснить концепции ООП нетехническому человеку?

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

Они говорят, что вы действительно понимаете вещи, как только объясняете их кому-то еще, в этом случае, как бы вы объяснили терминологию и концепции ООП нетехническому человеку?

Я обычно пытаюсь описать объектно-ориентированное программирование на реальных примерах.

Например, я мог бы сказать, что класс называется Vehicleописывает минимальные вещи, которые транспортное средство. Я попрошу человека сказать мне, что он или она думает, что автомобиль. Иногда они говорят что-то вроде «Ну, как машина или грузовик», и я киваю и соглашусь с ними. Тогда я спрошу, в чем разница между легковым и грузовым автомобилем. Иногда они упоминают размер, иногда цель и другие вещи.

Затем я попрошу их забыть об автомобиле или грузовике и просто попросить их продолжить описание транспортного средства:

"О, хорошо, это движется"

«У него есть оператор или водитель»

так далее...

Вскоре мы знаем, что такое Автомобиль, и я сказал, что в ООП мы определим транспортное средство и ради аргумента скажем, что оно может двигаться, и дадим ему своего рода водителя. Тогда я спрошу, хорошо, так что у машины?

«Дверь»

"Windows"

А потом грузовик ....

«Двери», «окна», «Больше колес!»

Вскоре после долгих обсуждений другой человек, как правило, определил:

1) Что представляет собой транспортное средство

2) Из чего состоит автомобиль

3) Из чего состоит грузовик

4) Из чего состоит самолет.

Все без каких-либо технических деталей. Мы разделили свойства каждого в правильные области. Они понимают наследование («Да, машина - это транспортное средство, грузовик - это транспортное средство, но автомобиль - это не грузовик, это ПРОСТО, да!»).

Они даже понимают полиморфизм: «Конечно, они в основном делают то же самое, но это может сделать это немного иначе». Мы можем говорить о поведении и о том, где оно должно жить в нашем дереве объектов.

В зависимости от их образования и происхождения, некоторые получают это быстрее, чем другие. Но когда я сравниваю ООП с реальными объектами, большинство людей всегда получают это. В разговорах с нетехническими людьми я обнаружил вещи, о которых никогда не думал. Транспортные средства необязательно должны быть укомплектованы, например (дроны), но может ли программист считать оператора транспортного средства его собственностью? Я не говорю, что правильно или неправильно упоминать оператора, но это заставляет нас задуматься о том, что мы моделируем и чего мы пытаемся достичь при разработке программного обеспечения.

Теперь частичная специализация шаблонов, с другой стороны .... :)

Объекты - существительные, методы - глаголы.

Вот некоторая версия моего стандартного ответа, который я даю ультра нетехническому человеку:

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

Иногда нам нужно встраивать пользовательские представления реальности в новые или существующие приложения, которые отражают наши бизнес-процессы. Существует множество способов программирования, и один из наиболее распространенных способов программирования - это объектно-ориентированное программирование, где код, который мы создаем, специально разработан для воспроизведения концепций реальности. «Вещи» в действительности имеют атрибуты и поведение. Например, человек часто имеет руки и ноги, цвет волос, этническую принадлежность и может часто говорить и ходить.

Разговор и ходьба могут быть разными, например, на каком языке вы говорите, или на скорости или манере ходьбы.

Люди часто взаимодействуют с другими типами «вещей», будь то животные, другие люди, другие живые организмы или неодушевленные предметы. В действительности существуют темы, которые часто нуждаются в способе представления, такие как взаимодействие между «вещами», категоризация вещей и т. Д. Рассмотрим бизнес-процессы, которые происходят в нашей организации. Существует очень сложная «бизнес-логика», которая должна быть представлена ​​в программном обеспечении, используемом нашей организацией.

Объектно-ориентированное программирование предоставляет средства для точного представления этих «концепций реального мира» и «бизнес-логики».

-> Этого утверждения обычно достаточно, чтобы удовлетворить их любопытство (или, возможно, утомить их до слез), но если у них есть больше вопросов, приведенное выше утверждение (я считаю) закладывает достойную основу для того, куда может пойти разговор. Я не думаю, что нетехнический человек слишком озабочен технической терминологией, такой как «Абстракция», «Композиция», «Полиморфизм» и т. Д., Но если это так, язык, который я использовал в консервативном выражении, позволяет мне привести примеры на его основе.

Я всегда изучал ООП, как это:

У вас есть часы, и они показывают время - ну, в программировании вы складываете весь код и все, что вам нужно сделать, все вместе (звучит довольно очевидно, но люди не привыкли делать это в прежние времена). Во всяком случае, это называется инкапсуляция .

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

Кроме того, вы смотрите на часы, которые у меня есть на моем запястье, но вы можете посмотреть другие часы, которые выглядят по-разному, как напольные часы или цифровые часы. Это выглядит по-другому, но это все еще часы - ну, это называется полиморфизмом .

И вот у вас есть 3 угла объектно-ориентированного программирования. Все остальное - просто кодирование.

Я бы просто сказал им записаться на курс в ООП, если они действительно хотят это понять.

Я имею в виду все эти аналогии, такие как Car.startEngine (); Есть, давайте посмотрим правде в глаза - чистый рэп. Когда я впервые попал в ООП много лет назад, я обнаружил, что они только абстрагируют домен еще дальше.

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

Да, совершенно нормально объяснять списки и векторы, потому что это то, с чем мы в основном работаем, а не Car.Engine и PoliceMan.Arrest (если вы не являетесь разработчиком игр, но, опять же, вы все равно должны иметь свою долю бывший).

Возвращаясь к теме, я бы просто сказал им, что я создаю нематериальные объекты, которые существуют исключительно в сознании программиста для целей расчета заработной платы / игры, навигации / космического челнока и т. Д.

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

Я говорил об этом разговоре с моей женой об этом, в этом ответе здесь: /software/45464/how-to-convince-non-programmer-his-notions-about- компьютеры-это-неправильный / 45467 # 45467

РЕДАКТИРОВАТЬ: вопрос, на который я ответил там, модерируется, поэтому я перефразирую свой ответ здесь.

Сидя в ресторане с моей женой, она спросила меня: «Что означает объектно-ориентированное?»

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

Поэтому я вытащил пакет Splenda из контейнера. Я сказал: «Вот объект. Каковы его свойства?»

Она сказала: «Это прямоугольник, оно сделано из бумаги, оно содержит блестки, оно голубое, на нем есть печать».

Я взял пакет с сахаром. "Что у него общего с этим?"

Она сказала: «Прямоугольность, бумага, что есть печать».

Я сказал: «Как насчет того, что они оба содержат что-то сладкое?»

Она сказала: «Конечно».

Я сказал: «Итак, это оба примера того, что мы могли бы назвать абстрактным пакетом подсластителя. Платонический идеальный пакет подсластителя, если хотите».

Она сказала: «Конечно».

Я сказал: «И у каждого есть свойства, унаследованные от абстрактного пакета, а затем варианты того, что специфично для его типа вещей».

Она сказала: «Правильно. О! И если бы я захотел сделать, например, пакет с Сахарином, я бы взял общий и установил подробности об этом для Сахарина, и тогда я бы получил это!»

Я сказал: «Бинго: объектно-ориентированное программирование».

Мы с тобой знаем, что она интуитивно поняла свой путь к дизайну фабрики. Без разницы. Он иллюстрирует наследование, инкапсуляцию, идентичность класса объекта ... Хорошие вещи.

Этот вопрос кажется кандидатом на закрытие, тем не менее ...

Как и большинство вещей, ООП на самом деле очень просто объяснить на концептуальном уровне. Программисты моделируют объекты; а также:

• объекты имеют состояние (поля / элементы данных)
• объекты имеют действия (методы / функции)
• объекты строятся друг на друге (наследование)

Это сотни мелких деталей, конечно. Но если вы просто пытаетесь дать кому-то 10-секундный обзор, я думаю, это хорошее начало. Есть ли у вас какие-то более специфические концепции, которые вам сложно объяснить?

Пример мобильного телефона:

Представьте, что вы владелец фабрики, вы хотите описать общий телефон

• Шаг 1. Перечислите эти общие свойства телефонов, например: рост, вес, цвет и т. Д.
• Шаг 2: Перечислите эти общие функции телефонов, например: сделать звонок, принять звонок, отправить смс и т. Д.

Теперь, когда у вас есть свой общий план, создайте мне следующие телефоны:

Телефон 1:

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

• Вес-> 85 г

• Цвет-> розовый

Телефон 2:

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

• Вес-> 96 г

• Цвет-> красный

Я думаю, что лучший способ объяснить нетрадиционному типу ООП - это связать его с ними.

По сути, OOD & OOP хотят, чтобы вы думали о системе, которую вы разрабатываете и внедряете, как мир взаимодействующих вещей.

Итак, позвольте, ради аргумента (который никогда не идет хорошо в Интернете), сказать, что вы объясняете сборщику мусора о OOD & P. Его зовут Боб. Вы ходили с ним в школу 15 лет назад, вы столкнулись с ним в баре, и вы оба симулируете интерес к жизни друг друга.

«Итак, Джон, ты говоришь, что ты программист. Мой племянник увлечен всей этой ерундой. Продолжает заниматься объектно-ориентированным программированием или чем-то в этом роде. О чем все это?» Обратите внимание, что Боб британец по тому, как он ориентировал орфографические ошибки.

«Ну, Боб», - отвечаете вы, цепляясь за ориентацию. «Это действительно очень просто. Ты собираешь мусор, верно? Что, вообще, ты работаешь?»

«Ну, я следую за фургоном по городу, собирая мусор и складывая его в фургон», - насмешливо отвечает Боб.

и вам нужно будет прислушиваться к этому. Это наше поведение. Это по сути все, что вам нужно для дизайна. Объектно-ориентированное программирование - это, по сути, способ реализации проекта. Это отличается от языка к языку. "

Боб заснул в своем пиве. Вы уходите.

Мне нравится пример автомобиля для объяснения наследования (я склонен использовать животных, а не транспортные средства, но это та же идея), но для объяснения того, как работает объектно-ориентированная программа, я ссылаюсь на аналогию, которую я однажды прочитал на веб-сайте Криса Кроуфорда: программа похожа на действительно эффективная бюрократия. Все различные объекты в программе похожи на различные отделы бюрократии; у каждого отдела есть свои собственные задачи, у них есть четко определенные входные данные (с кем разговаривать и какие формы заполнять), и другие отделы часто не знают так много о том, что происходит внутри. HR - это как абстрактная фабрика, IT - это синглтон и т. Д.

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

ООП является грубым упрощением - абстракцией - человеческого мыслительного процесса и понимания мира, чтобы проектировать функциональность в цифровую «пустоту», чтобы имитировать знакомые процессы и классификации в цифровом виде. Во многих отношениях речь идет о нашем примитивном языковом состоянии, а не о том, что мы «думаем больше как компьютеры».

Если бы программирование имитировало реальность или человеческую мысль, это было бы гораздо более органичным, хаотичным и случайным по своей природе - даже боковым. Вместо этого мы упрощаем реальность в виде маленьких шагов, «логики 2 + 2», грубых категорий, небольших инструментов многократного использования и доисторических рассуждений.

Мы все еще пытаемся решить, как загрузить наши мысли и желания в протокол и общий язык, и я думаю, историки будут однажды очарованы его изощренной грубостью - как мы теперь видим иероглифы. Это совсем не «умно» - это просто подчеркивает, как мы не можем легко объяснить, как мы решаем или понимаем даже самые простые вещи. Компьютерные технологии все еще находятся на уровне эволюции мышления «собака - это собака, потому что это не кошка» - это тысячелетия позади даже базового разговорного языка.

Есть два вида волшебников. Есть парень, который делает определенные вещи волшебными словами. У него есть слово для вызова огня. У него есть слово, чтобы заставить замороженную курицу появиться из воздуха. И еще одно слово для создания банка силы (я предпочитаю, чтобы моя сила была зеленой, сияющей и полупрозрачной), полной буйной добродетели. При правильном применении его слов он может производить жареную курицу.

И еще есть мастер ООП. Кто просто вызывает беса, который знает, как пойти в продуктовый магазин, купить курицу (или ингредиенты для любой другой еды, которую вы хотите, чтобы он приготовил), приготовить ее и подать на ужин. Волшебнику ООП не нужно рассказывать своему чертенку, как это сделать. Ему просто нужно сообщить ему, чего он хочет, в данном случае это жареная курица. Мало того, мастер ООП может призвать других миньонов, чтобы сказать своему шеф-повару, что делать.

Итак, парень-заклинатель впечатляет на вечеринках, но мастер ООП - это тот, который вам нужен, когда вы собираетесь открыть волшебный ресторан с кучей персонажей (например, разозленный официант-единорог и менеджер троллей), которые все должны работать вместе. Если вы попытаетесь на каждом этапе решить проблему «ресторана», вы легко запутаетесь в деталях, и на самом деле легко ошибиться. Мастер ООП заранее обучает своих миньонов разбираться в деталях для него, чтобы он мог просто сосредоточиться на решении большой проблемы, взаимодействуя со своими людьми.

Не говоря уже о том, что легче использовать своего шефа-беса для решения проблемы с кафетерием в начальной школе, тогда нужно отделить весь мусор, который вы можете или не можете использовать повторно, когда вы делаете все это по одному шагу за один раз, называя слова и слова, которые вызывают другие наборы слов (которые будут становиться все более многочисленными, поскольку вам придется справляться с большим разнообразием проблем).

Чтобы быть справедливым, с очень, очень осторожным применением, мастер заклинаний может сделать все это так же быстро, как мастер ООП. Он может разбить вещи правильным образом, так что вызов правильных заклинаний не требует больше работы с его стороны, чем мастер ООП. Но эту работу гораздо сложнее понять или воспроизвести, и гораздо труднее повторно использовать большие ее части, поскольку все они связаны друг с другом для решения одной конкретной сложной проблемы.