Я часто стараюсь не говорить людям, что я программист, потому что большую часть времени я объясняю им, что это на самом деле означает. Когда я говорю им, что я программирую на Java, они часто задают общие вопросы о языке и о том, чем он отличается от x и y. Я также не очень хорошо объясняю вещи, потому что 1) у меня нет такого большого опыта в этой области и 2) я действительно ненавижу объяснять вещи нетехническим людям.
Они говорят, что вы действительно понимаете вещи, как только объясняете их кому-то еще, в этом случае, как бы вы объяснили терминологию и концепции ООП нетехническому человеку?
Ответы:
Я обычно пытаюсь описать объектно-ориентированное программирование на реальных примерах.
Например, я мог бы сказать, что класс называется
Vehicleописывает минимальные вещи, которые транспортное средство. Я попрошу человека сказать мне, что он или она думает, что автомобиль. Иногда они говорят что-то вроде «Ну, как машина или грузовик», и я киваю и соглашусь с ними. Тогда я спрошу, в чем разница между легковым и грузовым автомобилем. Иногда они упоминают размер, иногда цель и другие вещи.Затем я попрошу их забыть об автомобиле или грузовике и просто попросить их продолжить описание транспортного средства:
"О, хорошо, это движется"
«У него есть оператор или водитель»
так далее...
Вскоре мы знаем, что такое Автомобиль, и я сказал, что в ООП мы определим транспортное средство и ради аргумента скажем, что оно может двигаться, и дадим ему своего рода водителя. Тогда я спрошу, хорошо, так что у машины?
«Дверь»
"Windows"
А потом грузовик ....
«Двери», «окна», «Больше колес!»
Вскоре после долгих обсуждений другой человек, как правило, определил:
1) Что представляет собой транспортное средство
2) Из чего состоит автомобиль
3) Из чего состоит грузовик
4) Из чего состоит самолет.
Все без каких-либо технических деталей. Мы разделили свойства каждого в правильные области. Они понимают наследование («Да, машина - это транспортное средство, грузовик - это транспортное средство, но автомобиль - это не грузовик, это ПРОСТО, да!»).
Они даже понимают полиморфизм: «Конечно, они в основном делают то же самое, но это может сделать это немного иначе». Мы можем говорить о поведении и о том, где оно должно жить в нашем дереве объектов.
В зависимости от их образования и происхождения, некоторые получают это быстрее, чем другие. Но когда я сравниваю ООП с реальными объектами, большинство людей всегда получают это. В разговорах с нетехническими людьми я обнаружил вещи, о которых никогда не думал. Транспортные средства необязательно должны быть укомплектованы, например (дроны), но может ли программист считать оператора транспортного средства его собственностью? Я не говорю, что правильно или неправильно упоминать оператора, но это заставляет нас задуматься о том, что мы моделируем и чего мы пытаемся достичь при разработке программного обеспечения.
Теперь частичная специализация шаблонов, с другой стороны .... :)
источник
Объекты - существительные, методы - глаголы.
источник
Вот некоторая версия моего стандартного ответа, который я даю ультра нетехническому человеку:
Программирование - это попытка создать представление реальности на компьютере. Существует множество инструментов и устройств, которые уже делают это - подумайте о том, как электронная таблица облегчает нам представление учета или статистики, или как презентация Powerpoint позволяет нам хранить и отображать наши презентации.
Иногда нам нужно встраивать пользовательские представления реальности в новые или существующие приложения, которые отражают наши бизнес-процессы. Существует множество способов программирования, и один из наиболее распространенных способов программирования - это объектно-ориентированное программирование, где код, который мы создаем, специально разработан для воспроизведения концепций реальности. «Вещи» в действительности имеют атрибуты и поведение. Например, человек часто имеет руки и ноги, цвет волос, этническую принадлежность и может часто говорить и ходить.
Разговор и ходьба могут быть разными, например, на каком языке вы говорите, или на скорости или манере ходьбы.
Люди часто взаимодействуют с другими типами «вещей», будь то животные, другие люди, другие живые организмы или неодушевленные предметы. В действительности существуют темы, которые часто нуждаются в способе представления, такие как взаимодействие между «вещами», категоризация вещей и т. Д. Рассмотрим бизнес-процессы, которые происходят в нашей организации. Существует очень сложная «бизнес-логика», которая должна быть представлена в программном обеспечении, используемом нашей организацией.
Объектно-ориентированное программирование предоставляет средства для точного представления этих «концепций реального мира» и «бизнес-логики».
-> Этого утверждения обычно достаточно, чтобы удовлетворить их любопытство (или, возможно, утомить их до слез), но если у них есть больше вопросов, приведенное выше утверждение (я считаю) закладывает достойную основу для того, куда может пойти разговор. Я не думаю, что нетехнический человек слишком озабочен технической терминологией, такой как «Абстракция», «Композиция», «Полиморфизм» и т. Д., Но если это так, язык, который я использовал в консервативном выражении, позволяет мне привести примеры на его основе.
источник
Я всегда изучал ООП, как это:
У вас есть часы, и они показывают время - ну, в программировании вы складываете весь код и все, что вам нужно сделать, все вместе (звучит довольно очевидно, но люди не привыкли делать это в прежние времена). Во всяком случае, это называется инкапсуляция .
Теперь у вас есть часы, вы можете захотеть будильник - ну, когда вы собрали все это вместе, вы можете добавить к нему вещи, чтобы заставить его делать больше - например, установить будильник и включить его. Это называется наследством .
Кроме того, вы смотрите на часы, которые у меня есть на моем запястье, но вы можете посмотреть другие часы, которые выглядят по-разному, как напольные часы или цифровые часы. Это выглядит по-другому, но это все еще часы - ну, это называется полиморфизмом .
И вот у вас есть 3 угла объектно-ориентированного программирования. Все остальное - просто кодирование.
источник
Я бы просто сказал им записаться на курс в ООП, если они действительно хотят это понять.
Я имею в виду все эти аналогии, такие как Car.startEngine (); Есть, давайте посмотрим правде в глаза - чистый рэп. Когда я впервые попал в ООП много лет назад, я обнаружил, что они только абстрагируют домен еще дальше.
Вместо того, чтобы просто объяснять, что ООП - это управление сложностью процедурных языков, почти 80% авторов книг по программированию предполагают, что программисты - это невежественные идиоты, о которых нужно говорить простыми (см. Здесь ирония?) Терминами.
Да, совершенно нормально объяснять списки и векторы, потому что это то, с чем мы в основном работаем, а не Car.Engine и PoliceMan.Arrest (если вы не являетесь разработчиком игр, но, опять же, вы все равно должны иметь свою долю бывший).
Возвращаясь к теме, я бы просто сказал им, что я создаю нематериальные объекты, которые существуют исключительно в сознании программиста для целей расчета заработной платы / игры, навигации / космического челнока и т. Д.
Если у них все еще есть вопросы, прекратите обсуждать, потому что это того не стоит. Большинство людей не в состоянии представить абстрактные понятия и нуждаются в примерах практически для всего (что на самом деле означает большее упрощение / специализацию актуальной темы).
источник
Car.startEngine()вещи сделают программирование простым для всех и интуитивно понятным для непрограммиста или новичка.Я говорил об этом разговоре с моей женой об этом, в этом ответе здесь: /software/45464/how-to-convince-non-programmer-his-notions-about- компьютеры-это-неправильный / 45467 # 45467
РЕДАКТИРОВАТЬ: вопрос, на который я ответил там, модерируется, поэтому я перефразирую свой ответ здесь.
Сидя в ресторане с моей женой, она спросила меня: «Что означает объектно-ориентированное?»
Я начал болтать о повторном использовании кода, инкапсуляции и полиморфизме, и в какой-то момент я понял, что ее глаза были окончательно застеклены.
Поэтому я вытащил пакет Splenda из контейнера. Я сказал: «Вот объект. Каковы его свойства?»
Она сказала: «Это прямоугольник, оно сделано из бумаги, оно содержит блестки, оно голубое, на нем есть печать».
Я взял пакет с сахаром. "Что у него общего с этим?"
Она сказала: «Прямоугольность, бумага, что есть печать».
Я сказал: «Как насчет того, что они оба содержат что-то сладкое?»
Она сказала: «Конечно».
Я сказал: «Итак, это оба примера того, что мы могли бы назвать абстрактным пакетом подсластителя. Платонический идеальный пакет подсластителя, если хотите».
Она сказала: «Конечно».
Я сказал: «И у каждого есть свойства, унаследованные от абстрактного пакета, а затем варианты того, что специфично для его типа вещей».
Она сказала: «Правильно. О! И если бы я захотел сделать, например, пакет с Сахарином, я бы взял общий и установил подробности об этом для Сахарина, и тогда я бы получил это!»
Я сказал: «Бинго: объектно-ориентированное программирование».
Мы с тобой знаем, что она интуитивно поняла свой путь к дизайну фабрики. Без разницы. Он иллюстрирует наследование, инкапсуляцию, идентичность класса объекта ... Хорошие вещи.
источник
Этот вопрос кажется кандидатом на закрытие, тем не менее ...
Как и большинство вещей, ООП на самом деле очень просто объяснить на концептуальном уровне. Программисты моделируют объекты; а также:
Это сотни мелких деталей, конечно. Но если вы просто пытаетесь дать кому-то 10-секундный обзор, я думаю, это хорошее начало. Есть ли у вас какие-то более специфические концепции, которые вам сложно объяснить?
источник
Пример мобильного телефона:
Представьте, что вы владелец фабрики, вы хотите описать общий телефон
Теперь, когда у вас есть свой общий план, создайте мне следующие телефоны:
Телефон 1:
Высота-> 102 мм
Вес-> 85 г
Цвет-> розовый
Телефон 2:
Высота-> 125мм
Вес-> 96 г
Цвет-> красный
источник
Я думаю, что лучший способ объяснить нетрадиционному типу ООП - это связать его с ними.
По сути, OOD & OOP хотят, чтобы вы думали о системе, которую вы разрабатываете и внедряете, как мир взаимодействующих вещей.
Итак, позвольте, ради аргумента (который никогда не идет хорошо в Интернете), сказать, что вы объясняете сборщику мусора о OOD & P. Его зовут Боб. Вы ходили с ним в школу 15 лет назад, вы столкнулись с ним в баре, и вы оба симулируете интерес к жизни друг друга.
«Итак, Джон, ты говоришь, что ты программист. Мой племянник увлечен всей этой ерундой. Продолжает заниматься объектно-ориентированным программированием или чем-то в этом роде. О чем все это?» Обратите внимание, что Боб британец по тому, как он ориентировал орфографические ошибки.
«Ну, Боб», - отвечаете вы, цепляясь за ориентацию. «Это действительно очень просто. Ты собираешь мусор, верно? Что, вообще, ты работаешь?»
«Ну, я следую за фургоном по городу, собирая мусор и складывая его в фургон», - насмешливо отвечает Боб.
и вам нужно будет прислушиваться к этому. Это наше поведение. Это по сути все, что вам нужно для дизайна. Объектно-ориентированное программирование - это, по сути, способ реализации проекта. Это отличается от языка к языку. "
Боб заснул в своем пиве. Вы уходите.
источник
Мне нравится пример автомобиля для объяснения наследования (я склонен использовать животных, а не транспортные средства, но это та же идея), но для объяснения того, как работает объектно-ориентированная программа, я ссылаюсь на аналогию, которую я однажды прочитал на веб-сайте Криса Кроуфорда: программа похожа на действительно эффективная бюрократия. Все различные объекты в программе похожи на различные отделы бюрократии; у каждого отдела есть свои собственные задачи, у них есть четко определенные входные данные (с кем разговаривать и какие формы заполнять), и другие отделы часто не знают так много о том, что происходит внутри. HR - это как абстрактная фабрика, IT - это синглтон и т. Д.
Получение сообщения об ошибке, потому что вы ввели неправильный текст в компьютерную программу, точно так же, как заполнение формы для отправки в офис.
источник
ООП является грубым упрощением - абстракцией - человеческого мыслительного процесса и понимания мира, чтобы проектировать функциональность в цифровую «пустоту», чтобы имитировать знакомые процессы и классификации в цифровом виде. Во многих отношениях речь идет о нашем примитивном языковом состоянии, а не о том, что мы «думаем больше как компьютеры».
Если бы программирование имитировало реальность или человеческую мысль, это было бы гораздо более органичным, хаотичным и случайным по своей природе - даже боковым. Вместо этого мы упрощаем реальность в виде маленьких шагов, «логики 2 + 2», грубых категорий, небольших инструментов многократного использования и доисторических рассуждений.
Мы все еще пытаемся решить, как загрузить наши мысли и желания в протокол и общий язык, и я думаю, историки будут однажды очарованы его изощренной грубостью - как мы теперь видим иероглифы. Это совсем не «умно» - это просто подчеркивает, как мы не можем легко объяснить, как мы решаем или понимаем даже самые простые вещи. Компьютерные технологии все еще находятся на уровне эволюции мышления «собака - это собака, потому что это не кошка» - это тысячелетия позади даже базового разговорного языка.
источник
Есть два вида волшебников. Есть парень, который делает определенные вещи волшебными словами. У него есть слово для вызова огня. У него есть слово, чтобы заставить замороженную курицу появиться из воздуха. И еще одно слово для создания банка силы (я предпочитаю, чтобы моя сила была зеленой, сияющей и полупрозрачной), полной буйной добродетели. При правильном применении его слов он может производить жареную курицу.
И еще есть мастер ООП. Кто просто вызывает беса, который знает, как пойти в продуктовый магазин, купить курицу (или ингредиенты для любой другой еды, которую вы хотите, чтобы он приготовил), приготовить ее и подать на ужин. Волшебнику ООП не нужно рассказывать своему чертенку, как это сделать. Ему просто нужно сообщить ему, чего он хочет, в данном случае это жареная курица. Мало того, мастер ООП может призвать других миньонов, чтобы сказать своему шеф-повару, что делать.
Итак, парень-заклинатель впечатляет на вечеринках, но мастер ООП - это тот, который вам нужен, когда вы собираетесь открыть волшебный ресторан с кучей персонажей (например, разозленный официант-единорог и менеджер троллей), которые все должны работать вместе. Если вы попытаетесь на каждом этапе решить проблему «ресторана», вы легко запутаетесь в деталях, и на самом деле легко ошибиться. Мастер ООП заранее обучает своих миньонов разбираться в деталях для него, чтобы он мог просто сосредоточиться на решении большой проблемы, взаимодействуя со своими людьми.
Не говоря уже о том, что легче использовать своего шефа-беса для решения проблемы с кафетерием в начальной школе, тогда нужно отделить весь мусор, который вы можете или не можете использовать повторно, когда вы делаете все это по одному шагу за один раз, называя слова и слова, которые вызывают другие наборы слов (которые будут становиться все более многочисленными, поскольку вам придется справляться с большим разнообразием проблем).
Чтобы быть справедливым, с очень, очень осторожным применением, мастер заклинаний может сделать все это так же быстро, как мастер ООП. Он может разбить вещи правильным образом, так что вызов правильных заклинаний не требует больше работы с его стороны, чем мастер ООП. Но эту работу гораздо сложнее понять или воспроизвести, и гораздо труднее повторно использовать большие ее части, поскольку все они связаны друг с другом для решения одной конкретной сложной проблемы.
источник