Как преподавать объектно-ориентированное программирование процедурным программистам? [закрытый]

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

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

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

Стоимость. Объясните, как при правильном использовании функции языка должны позволять писать и поддерживать программное обеспечение с меньшими затратами. (например, в Java Foo.getBar () вместо foo-> bar, который так часто встречается в коде C / C ++).
В противном случае, зачем мы это делаем?

Я профессионально занимаюсь объектно-ориентированным проектированием, но в моей команде разработчиков были процедурные разработчики (они разрабатывали код Matlab, так что это работало). Одна из концепций, которые мне нравятся в объектно-ориентированном программировании, - это то, как объекты могут быть связаны с вашим доменом ( http://en.wikipedia.org/wiki/Domain-driven_design - Эрик Эванс написал об этом книгу, но это ни в коем случае не книга для новичков.)

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

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

Показать шаблоны дизайна в примерах

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

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

Я также многому научился у таких гуру объектно-ориентированного программирования, как Роберт К. Мартин и его действительно замечательные статьи (которые можно найти на сайте его компаний).

Edit: Я также выступаю за использование UML (диаграмм классов) для обучения объектно-ориентированному программированию / шаблону проектирования.

Если они хорошие процедурные программисты и знают, что такое структура и указатель на функцию, самая сложная часть работа уже сделана!

Я думаю, что лекция низкого уровня о том, как объектно-ориентированное программирование может быть реализовано на процедурных языках или даже на ассемблере, могла бы быть крутой. Тогда они оценят объем работы, которую компилятор сделает за них; и, возможно, они найдут шаблоны кодирования, которые они уже знали и использовали ранее.

Затем вы можете поговорить о лучших практиках в хорошем объектно-ориентированном дизайне и немного познакомить с UML.

И очень важную вещь, которую нужно сохранить. всегда имейте в виду, что они не новички, не тратьте много времени на простые вещи, потому что им будет скучно.

Сначала определите объект, не используя какое-нибудь глупое животное, форму или пример транспортного средства, а с чем-то, что они уже знаете. Библиотека C stdio и структура FILE . Он используется как непрозрачная структура данных с определенными функциями. Сопоставьте это от процедурного использования до объектно-ориентированного использования, а затем перейдите к инкапсуляции, полиморфизму и т. Д.

Я бы порекомендовал взглянуть на Head First Design Patterns , где есть действительно приятные и простые для понимания примеры объектно-ориентированного дизайна, которые действительно должны помочь. Однако я бы не стал особо подчеркивать аспект «паттернов» на данном этапе.

Я немного удивлен, что остались какие-то чисто процедурные программисты; -)

Но, как человек, который начал кодировать еще в начале 80-х на процедурных языках, таких как COBOL, C и FORTRAN, Я помню, что у меня были самые большие трудности с созданием экземпляров. Сама концепция объекта не была такой сложной, поскольку в основном это `` структуры с присоединенными методами '' (если смотреть с процедурной точки зрения), но обработка того, как и когда я создавал экземпляр объекта - а в те дни без сборки мусора - уничтожала их, вызывала у меня проблемы.

Я думаю, это возникает потому, что в некотором смысле процедурный программист может обычно указывать на любую переменную в своем коде, любой говорит, где этот элемент данных непосредственно хранится, тогда как как только вы создали экземпляр объекта и присвоили значения к этому тогда это ' s гораздо менее ощутимы (использование указателей и распределение памяти в C, конечно, аналогично, что может быть полезной отправной точкой также, если ваши ученики имеют опыт C). По сути, я полагаю, это означает, что ваш процедурный программист -> OOPS должен научиться обрабатывать другой уровень абстракции в своем коде, и освоиться с этим мысленным шагом труднее, чем кажется. Таким образом, я хотел бы убедиться, что ваши ученики полностью знакомы с распределением объектов и управлением ими, прежде чем рассматривать такие потенциально сбивающие с толку концепции, как статические методы.

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

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

Во-первых, выберите язык, например C # или Java, и приготовьте множество примеров для демонстрации. Всегда показывайте им общую картину или большую идею, прежде чем вдаваться в более тонкие детали объектно-ориентированных концепций, таких как абстракция или инкапсуляция. Будьте готовы ответить на множество вопросов о причинах с достаточным количеством реальных примеров.

The leap from procedural to object oriented (even within a language - for four months I programmed procedural C++, and classes were uncomfortable for a while after) can be eased if you emphasize the more basic concepts that people don't emphasize.

For instance, when I first learned OOP, none of the books emphasized that each object has its own set of data members. I was trying to write classes for input validation and the like, not understanding that classes were to operate on data members, not input.

Get started with data structures right away. They make the OOP paradigm seem useful. People teach you how to make a "House" class, but since most beginning programmers want to do something useful right away, that seems like a useless detour.

Avoid polymorphism right away. Inheritance is alright, but teach when it is appropriate (instead of just adding to your base class).

Operator overloading is not essential when you are first learning, and the special ctors (default, dtor, copy ctor, and assignment operator all have their tricky aspects, and you might want to avoid that until they are grounded in basic class design).

Have them build a Stack or a Linked List. Don't do anything where traversal is tricky, like a binary tree.

Делайте это поэтапно.

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

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

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

Продвинутые концепции: SOLID, программирование интерфейсов, шаблоны проектирования OO.

Научите рефакторингу

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

Традиционный способ: абстракции> Облако жаргонов> Простая реализация> Практическое использование (Вы можете заметить здесь несоответствие? Один из этих переходов сложнее, чем другие.)

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

Обеспечьте контраст, чтобы заострить внимание на ценности объектно-ориентированного подхода

Обучайте студентов, заранее предоставляя им инструменты для улучшения объектно-ориентированного проектирования существующего кода посредством рефакторинга. Возьмите большой объем процедурного кода, несколько раз используйте метод extract, используя значимые имена методов, определите группы методов, которые имеют общие черты, и перенесите их в свой собственный класс. Замените переключатель / корпуса на полиморфизм. И т.д. У этого много преимуществ. Это дает студентам опыт чтения и работы с существующим кодом, что является ключевым навыком. Это дает более полное представление о деталях и преимуществах объектно-ориентированного проектирования. Трудно оценить достоинства конкретного шаблона проектирования OO в вакууме, но сравнение его с более процедурным стилем или более неуклюжим дизайном OO ставит эти достоинства в резкий контраст.

Формирование знаний с помощью ментальных моделей и выразительной терминологии

Язык и терминология рефакторинга помогают студентам понять объектно-ориентированный дизайн, как судить о качестве объектно-ориентированных проектов и реализаций на основе идеи запаха кода. Он также предоставляет студентам основу для обсуждения концепций объектно-ориентированного программирования со своими сверстниками. Без моделей и терминологии, скажем, автомобильной трансмиссии, механикам было бы трудно общаться друг с другом и разбираться в автомобилях. То же самое относится к объектно-ориентированному проектированию и разработке программного обеспечения. Рефакторинг предоставляет обширную терминологию и ментальные модели (шаблоны проектирования, запахи кода и соответствующие предпочтительные конкретные рефакторинги и т. Д.) Для компонентов и методов разработки программного обеспечения.

Формируйте этику мастерства

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

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

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

Эта функция уже встроена в Sql Server Management Studio 2008.

Просто загрузите пробную версию и установите только клиентские инструменты (срок действия которых не должен истекать). Используйте Management Studio 2008 для подключения к базе данных 2005 (ее обратно совместимой).

1. Щелкните правой кнопкой мыши базу данных
2. Выберите Задачи > Создать сценарии
3. Нажмите Далее, снова выберите базу данных
4. На экране «Выбрать параметры сценария» есть параметр Данные сценария , который генерирует операторы вставки SQL для всех ваших данных.

(Примечание: для SQL Server Management Studio 2008 R2, эта опция называется «Типы данных для скрипта» и является последней в разделе «Общие». Возможные варианты: «только данные», «схема и данные» и « Первое, что я сделал, это познакомился со статической областью видимости.

Java - хороший язык для начала объектно-ориентированного программирования, потому что он пытается оставаться верным всем различным парадигмам объектно-ориентированного программирования.

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

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

Первое, что я сделал, - это познакомился со статической областью видимости.

Java - хороший язык для начала объектно-ориентированного программирования, потому что он пытается оставаться верным всем различным парадигмам объектно-ориентированного программирования.

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

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

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

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

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

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

Я нашел книгу Concepts , Методы и модели компьютерного программирования , чтобы помочь мне понять и дать мне словарный запас для обсуждения различий в языковых парадигмах. В книге не рассматриваются Java или C # как 00-языки, а рассматриваются концепции различных парадигм. Если бы я обучал объектно-ориентированному программированию, я бы начал с демонстрации различий в парадигмах, а затем постепенно различий в 00-языках, практических материалах, которые они могут усвоить сами, выполняя курсовые работы / проекты.

Я бы избегал слов "велосипед - это своего рода of veichle "и попытайтесь применить объектно-ориентированный подход к среде, которая довольно специфична и к которой они уже привыкли. Попытайтесь найти область проблем, которую все они признают.

Изучите основы в этой области, но попытайтесь перейти к некоторому "вау!" или "ага!" опыт относительно рано; У меня был подобный опыт, когда я читал о « Заменить условное на полиморфизм » в Fowlers Refactoring эта или аналогичные книги могут быть хорошим источником идей. Если я правильно помню, Майкл Фезерс Эффективная работа с унаследованным кодом содержит главу о том, как преобразовать процедурную программу в объектно ориентированный объект.

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

То, что заставило меня щелкнуть, было введение рефакторинга и модульного тестирования. Большую часть моей профессиональной карьеры программиста я провел в объектно-ориентированных языках, но большую часть времени я посвятил написанию процедурного кода. Вы вызываете функцию в экземпляре класса X, а она вызывает другой метод в экземпляре класса Y. Я не понимал, в чем состоит проблема интерфейсов, и думал, что наследование - это просто концепция удобства, а классы были в общем и целом способом помочь нам отсортировать и классифицировать массивный код. Если бы кто-то был достаточно мазохистом, он мог бы легко пройти через некоторые из моих старых проектов и встроить все, пока вы не дойдете до одного огромного класса. Я до сих пор очень смущен тем, насколько плохим был мой код, насколько наивной была моя архитектура.

Он наполовину щелкнул, когда мы прошли через Мартина Фаулера ' s книгу по рефакторингу, а затем полностью щелкнули, когда начали писать тесты Unit и Fitnesse для нашего кода, что вынудило нас провести рефакторинг. Начните продвигать рефакторинг, внедрение зависимостей и разделение кода на отдельные модели MVC. Либо он утонет, либо их головы взорвутся.

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