Меня попросили начать преподавание концепций С# и OO группе процедурных программистов. Я искал идеи о том, с чего начать, но я ищу общий консенсус по темам, которые должны вести в дополнение к темам, которые изначально следует избегать.
Edit
Я собираюсь представить информацию в 30-минутных выпусках еженедельно, пока не будет смысла встречаться. Эти презентации ориентированы на сотрудников со множеством навыков от начинающих до экспертов.
Лучшее, что вы можете сделать, это: У вас есть тонна Q & A.
Wikipedia процедурное программирование (PP) статья действительно попадает туда, где вы должны начать:
В то время как процедурное программирование использует процедуры для работы с данными структур, объектно-ориентированных программирование связывает два поэтому "объект" действует на своих "собственных" структуры данных.
Как только это будет понято, я думаю, что многое встанет на свои места.
Обычно
ООП - это одна из тех вещей, которые могут занять время, чтобы "добраться", и каждый человек берет свой собственный путь, чтобы добраться туда. При написании на С# это не похоже на крики кода, " Я использую принципы OO!" в каждой строке. Это более тонкая вещь, например, цикл foreach или string.
Центр дизайна
Всегда используйте что-то (повторно) перед его созданием.
Сначала используйте объект и продемонстрируйте основные отличия от PP. Как:
static void Main(string[] args)
{
List<int> myList = new List<int>();
myList.Add(1);
myList.Add(7);
myList.Add(5);
myList.Sort();
for (int i = 0; i < myList.Count; i++)
{
Console.WriteLine(myList[i]);
}
}
Использование объектов (и других вещей OO) сначала - прежде чем заставить их создавать свои собственные - ведет людей по пути "Хорошо, я делаю что-то вроде того, что я использовал", а не "WTF am Я печатаю?
Наследование (это ловушка!)
Я бы не потратил много времени на наследование. Я думаю, что это общая ошибка для уроков, чтобы сделать большую сделку об этом (как правило, создавая иерархию животных клише, как указывали другие). Я думаю, что важно знать о наследовании, понять, как использовать .NET Framework, но его нюансы не так уж важны.
Когда я использую .NET, я с большей вероятностью "запускаю наследование", когда я использую .NET Framework (т.е. имеет ли этот элемент управления свойство Content? "или" я просто вызовите его метод ToString().), а не когда я создаю свой собственный класс. Очень (очень (очень)) редко я чувствую необходимость сделать что-то, имитирующую таксономическую структуру животного мира.
Интерфейсы
Кодирование интерфейса - ключевая концепция среднего уровня. Он используется повсюду, и ООП облегчает его работу. Примеры этого безграничны. Исходя из приведенного выше примера, можно было продемонстрировать интерфейс IComparer<int>:
public int Compare(int x, int y)
{
return y.CompareTo(x);
}
Затем используйте его, чтобы изменить порядок сортировки списка, через myList.Sort(this). (После разговора о this, конечно.)
Рекомендации
Так как в группе есть опытные разработчики, одна стратегия в классах среднего уровня будет показывать, как работают различные лучшие практики на С#. Например, скрытие информации, шаблон наблюдателя и т.д.
У вас есть тонна Q & A
Опять же, каждый учится немного по-другому. Я думаю, что самое лучшее, что вы можете сделать, это иметь тонну Q & A и поощрять других в группе к обсуждению. Люди обычно узнают больше, когда они участвуют, и у вас есть хорошая ситуация, когда это должно быть проще.
Переход от процедурного к объектно-ориентированному (даже в пределах языка - за четыре месяца я запрограммировал процедурный С++, а классы были неудобными в течение некоторого времени после) можно ослабить, если подчеркнуть более основные понятия, которые люди не подчеркивают.
Например, когда я впервые узнал ООП, ни одна из книг не подчеркнула, что каждый объект имеет свой собственный набор элементов данных. Я пытался писать классы для проверки ввода и т.д., Не понимая, что классы должны работать с данными, а не вводить.
Начните работу с структурами данных сразу. Они делают парадокс ООП полезным. Люди учат вас, как сделать класс "Дом", но так как большинство начинающих программистов хотят сделать что-то полезное сразу, это кажется бесполезным обходом.
Избегайте полиморфизма сразу. Наследование - это хорошо, но учите, когда это уместно (вместо того, чтобы просто добавлять ваш базовый класс).
Перегрузка оператора не является существенной, когда вы впервые изучаете, а специальные ctors (по умолчанию, dtor, copy ctor и оператор присваивания имеют свои сложные аспекты, и вы можете избежать этого, пока они не основаны на базовом классе).
Попросите их создать стек или связанный список. Не делайте ничего, где обход сложен, как двоичное дерево.
Сделайте это поэтапно.
Концепции высокого уровня: Опишите, что такое объект и связать его с реальной жизнью.
Концепции среднего уровня: теперь, когда они получили какой-то объект, попробуйте сравнить и сравнить. Покажите им, почему глобальная переменная плоха по сравнению с инкапсулированным значением в классе. Какое преимущество они могут получить от инкапсуляции. Начните вводить тэны ООП (инкапсуляция, наследование)
Концепции низкого уровня: идите дальше в полиморфизм и абстрагирование. Покажите им, как они могут получить еще лучший дизайн благодаря полиморфизму и абстракции.
Предварительные концепции: SOLID, программирование интерфейса, шаблоны проектирования OO.
Возможно, вам стоит рассмотреть проблему, связанную с работой, и начать с ее процедурной реализации, а затем выполнить (сеанс за сеансом), как сделать реализацию ООП. Я считаю, что профессионалы часто лучше понимают концепции, если они напрямую связаны с реальными примерами из собственного места работы. Примеры нежелательной информации, используемые большинством учебников, часто ужасны для понимания, потому что они оставляют интерес ученика, почему бы мне никогда не захотелось этого сделать. Дайте им реальную жизнь, почему они захотят это сделать, и это имеет смысл.
Я бы избегал подхода "велосипед - это своего рода видхли" и пытаюсь применить OO к среде, которая достаточно специфична и к которой они уже привыкли. Попробуйте найти домен проблем, которые все они распознают.
Изучите основы этой области, но попытайтесь перейти к некоторым "вау!". или "ага!" опыт относительно рано; У меня был такой опыт, когда я читал "Заменить условный с полиморфизмом" в Fowlers "Рефакторинг" , что или подобные книги могут быть хорошим источником идей, Если я правильно помню, Michael Feathers Эффективная работа с устаревшим кодом содержит главу о том, как преобразовать процессуальную программу в OO.
Обучение рефакторингу
Научитесь основам, минимальному принципу OO, затем научите Refactoring практический.
Традиционный путь: абстракции > Облако жаргонa > Тривиальная реализация > Практическое использование (Можете ли вы заметить разрыв здесь? Один из этих переходов сложнее других.)
По моему опыту большинство традиционного образования не очень хорошо справляется с тем, чтобы программисты действительно набирали принципы OO. Вместо этого они изучают немного синтаксиса, на каком-то жаргоне они имеют смутное понимание и пару примеров канонического дизайна, которые служат в качестве шаблонов для многих, что они делают. Это легкие годы, связанные с глубоким пониманием дизайна и проектирования ОО, которые хотели бы получить от компетентных студентов. Результат, как правило, состоит в том, что код разбивается на большие куски в том, что лучше всего можно назвать объектно-библиотечными, а код номинально привязан к объектам и классам, но очень, очень далек от оптимального. Это чрезвычайно распространено, например, чтобы увидеть несколько сотен линейных методов, которые вообще не очень OO.
Обеспечить контрастность для резкости Фокус на значении OO
Учите учащихся, предоставив им инструменты для улучшения OO-дизайна существующего кода посредством рефакторинга. Возьмите большой фрагмент процедурного кода, используйте метод извлечения кучу раз, используя значащие имена методов, определите группы методов, которые разделяют общность и переносят их в свой класс. Замените переключатель/случаи полиморфизмом. И т.д. Преимущества этого много. Это дает студентам возможность читать и работать с существующим кодом, ключевым навыком. Он дает более полное представление о деталях и преимуществах дизайна OO. Трудно оценить достоинства конкретного шаблона проектирования OO в вакууме, но сравнение его с более процедурным стилем или неуклюжей конструкцией OO делает эти достоинства резким контрастом.
Построить знания через умственные модели и выразительную терминологию
Язык и терминология рефакторинга помогают учащимся в понимании дизайна OO, как судить о качестве проектов OO и реализаций посредством идеи запаха кода. Он также предоставляет студентам основу для обсуждения концепций ОО со своими сверстниками. Без моделей и терминологии, скажем, автомобильной передачи, механикам было бы трудно общаться друг с другом и понимать автомобили. То же самое касается проектирования OO и разработки программного обеспечения. Рефакторинг предоставляет обширную терминологию и умственные модели (шаблоны проектирования, запахи кода и соответствующие благоприятные специфические рефакторинги и т.д.) Для компонентов и методов разработки программного обеспечения.
Постройте этику мастерства
Обучая студентов тому, что дизайн не установлен в камне, вы укрепляете уверенность студентов в их способности экспериментировать, учиться и открывать. Попадая в руки, они будут чувствовать себя более уверенными в решении проблем разработки программного обеспечения. Эта уверенность и практические навыки позволят им по-настоящему владеть дизайном своей работы (потому что они всегда будут иметь навыки и опыт, чтобы изменить этот дизайн, если они пожелают). Эта собственность, мы надеемся, поможет укрепить чувство ответственности, гордости и мастерства.
Сначала выберите язык, например С# или Java, и у вас будет много образцов для демонстрации. Всегда показывайте им большую картину или большую идею, прежде чем вникать в более тонкие детали концепций ОО, таких как абстракция или инкапсуляция. Будьте готовы ответить на многие вопросы, связанные с достаточными примерами реального мира.
Сначала определите объект, не используя какую-то глупую фигуру животного, форму, автомобиль, но с тем, что они уже знают. Библиотека C stdio и структура FILE. Он используется как непрозрачная структура данных с определенными функциями. Карта, которая от процедурного использования до использования OO и перейти оттуда к инкапсуляции, полиморфизму и т.д.
Я удивлен, что у нас остались простые процедурные программисты, -)
Но, как кто-то, кто начал кодирование еще в начале 80-х годов на процедурных языках, таких как COBOL, C и FORTRAN, я помню, с чем я столкнулся, с большей сложностью, чем инстанцирование. Понятие самого объекта было не так сложно, поскольку в основном это "структуры с прикрепленными методами" (смотрел с процедурной точки зрения), но обрабатывал, как и когда я создавал экземпляр объекта - и в те дни без сбора мусора - уничтожил их мне немного неприятностей.
Я думаю, что это возникает из-за того, что в каком-то смысле процедурный программист может вообще указывать на любую переменную в своем коде, любой говорит, что где этот элемент данных хранится непосредственно, тогда как только вы создаете экземпляр объекта и присваиваете ему значения, тогда гораздо менее непосредственное осязаемое (с использованием указателей и распределения памяти в C, конечно, похоже, что может быть полезной отправной точкой, если у ваших учеников есть опыт C). По сути, я полагаю, это означает, что ваш процедурный программист → OOPS должен научиться обращаться с другим уровнем абстракции в своем коде, и удобство в этом умственном шаге сложнее, чем кажется. Поэтому я должен убедиться, что ваши ученики полностью согласны с распределением и обработкой объектов, прежде чем рассматривать такие потенциально запутывающие концепции как статические методы.
Я бы рекомендовал взглянуть на Head First Design Patterns, в котором есть действительно красивые и понятные примеры объектно-ориентированного дизайна, которые должны действительно помогают. Я бы не особо подчеркивал аспект "шаблонов" на этом этапе.
Я промежуточный программист vb.net, и я изучаю ООП. Одна из вещей, которую я нахожу, - лекция об этих концепциях снова и снова вызывает беспокойство. Я думаю, что идеальная документация будет постепенным переходом от процедурного программирования к полномасштабному ООП, а не попыткой заставить их понять концепции, а затем заставить их писать исключительно код ООП, используя все концепции. Таким образом, они могут возиться с небольшими проектами, такими как "привет мир", без запугивания дизайна.
Например (это для начинающих VB.NET непереработанных процедурных программистов).
Я думаю, что в первых главах всегда должны быть общие понятия, только с несколькими примерами, но вы не должны принуждать их правильно кодировать ООП, использовать их для языка, чтобы они были естественными для них. Когда я только начал, мне пришлось вернуться и снова прочитать руководство, чтобы вспомнить, КАК писать код, но мне пришлось пробираться по страницам и страницам лекций о концепциях. Болезненные! Мне просто нужно запомнить, как создать свойство ReadOnly или что-то еще. То, что было бы очень удобно, - это часть книги, которая является ссылкой на язык, поэтому вы можете легко найти ее, чтобы узнать, КАК писать код.
Затем вы кратко объясняете, как формы и все объекты уже являются объектами, которые имеют методы, и показывают, как они себя ведут, и пример кода.
Затем покажите им, как создать класс, и создайте класс, который имеет свойства, методы и новую конструкцию. Затем попросите их в основном переключиться с них с помощью процедурного кода в форме или модулях, чтобы написать методы для классов.
Затем вы просто вводите более предварительные коды, как и любой язык программирования. Покажите им, как работает наследование, и т.д. Просто продолжайте расширяться и позволяйте им использовать их творчество, чтобы узнать, что можно сделать.
После того, как они привыкнут к написанию и использованию классов, покажите, как их классы могут улучшиться, внедряя концепции один за другим в коде, модифицируя существующие проекты и улучшая их. Одна хорошая идея - взять примерный проект в процедурный код и преобразовать его в лучшее приложение в ООП, показывая им все ограничения ООП.
Теперь, когда это продвинутая часть, в которой вы попадаете в некоторые действительно продвинутые концепции ООП, так что люди, которые знакомы с ООП, уже получают какую-то ценность из книги.
Если они хорошие процедурные программисты и знают, что такое структура и указатель на функцию, самая сложная часть задания уже выполнена!
Я думаю, что лекция низкого уровня о том, как объектно-ориентированное программирование может быть реализована на процедурных языках или даже на ассемблере, может быть крутой. Затем они оценят объем работы, которую делает компилятор для них; и, возможно, они найдут шаблоны кодирования, которые они уже знали и использовали ранее.
Затем вы можете поговорить о лучших практиках в хорошем объектно-ориентированном дизайне и ввести немного UML.
И очень важно всегда помнить, что они не первокурсники, не тратят много времени на основные вещи, потому что им будет скучно.
Показать образцы дизайна в примерах
Там, где есть много хороших ответов, ладно. Я также думаю, что вы должны использовать хорошие языки, хорошие, умелые примеры, но у меня есть дополнительное предложение:
Я узнал, что означает ООП, изучая шаблоны проектирования. Конечно, я, конечно, раньше изучал язык OO, но пока я не работал над Design Patterns, я не понимал всей силы.
Я также многому научился у OO-гуру, такого как Роберт К. Мартин и его действительно хорошие статьи (которые можно найти на сайте своих компаний).
Изменить: я также рекомендую использовать UML (диаграммы классов) для обучения OO/Design-Pattern.
То, что заставило меня щелкнуть, было введение Refactoring и Unit Testing. Большая часть моей профессиональной карьеры программирования была в языках OO, но я потратил большую часть ее на написание процедурного кода. Вы вызываете функцию в экземпляре класса X, и он вызывает другой метод для экземпляра класса Y. Я не видел, что такое большая проблема в интерфейсах, и считал, что наследование было просто понятием удобства и классами были по большому счету способом помочь нам сортировать и классифицировать массивный код. Если бы кто-то был достаточно мазохист, они могли бы легко пройти через некоторые мои старые проекты и сделать все, пока не дойдете до одного массивного класса. Я все еще смущен тем, насколько плохо мой код, насколько наивна моя архитектура.
Он получил половину щелчка, когда мы просмотрели книгу рефакторинга Мартина Фаулера, а затем полностью нажали, когда начали проходить и записывали тесты Unit и Fitnesse для нашего кода, заставляя нас реорганизовывать. Начните нажимать рефакторинг, инъекцию зависимостей и разделение кода на отдельные модели MVC. Либо он утонет, либо их головы взорвутся.
Если кто-то действительно этого не понимает, возможно, они не вырезаны для работы над OO, но я не думаю, что кто-либо из нашей команды полностью потерялся, поэтому, надеюсь, вам повезет.
Я разработчик OO профессионально, но у меня были разработчики процедур в моей команде разработчиков (они разрабатывали код Matlab, так что это сработало). Одна из концепций, которые мне нравятся в программировании OO, - это то, как объекты могут относиться к вашему домену (http://en.wikipedia.org/wiki/Domain-driven_design - Эрик Эванс написал книгу об этом, но он не является книгой для начинающих ни на одном растяжке).
С учетом сказанного, я бы начал демонстрировать концепции OO на высоком уровне. Попробуйте, например, спроектировать автомобиль. Большинство людей скажут, что автомобиль имеет тело, двигатель, колеса и т.д. Объясните, как они могут относиться к объектам реального мира.
Как только они, похоже, поймут эту концепцию высокого уровня, я начну с ее фактической части кода и таких понятий, как наследование против агрегации, полиморфизма и т.д.
Я узнал об ООП во время моего послесреднего образования. Они довольно хорошо объяснили понятия, но полностью не смогли объяснить, почему и когда. Они, как они учили ООП, заключались в том, что абсолютно все должно было быть предметом, а процессуальное программирование по каким-то причинам было злым. Примеры, которые они нам давали, казались мне излишними, отчасти потому, что объекты не казались правильными решениями для каждой проблемы, а отчасти потому, что это казалось большим количеством лишних накладных расходов. Это заставило меня презирать ООП.
В те годы, прошедшие с тех пор, я стал любить ООП в ситуациях, когда это имеет смысл для меня. Лучший пример, который я могу придумать, - это самое последнее веб-приложение, которое я написал. Первоначально он бежал от отдельной базы данных, но во время разработки я решил связать ее с другой базой данных, чтобы импортировать информацию о новых пользователях, чтобы я мог настроить приложение автоматически (введите идентификатор сотрудника, получить имя и отдел), Каждая база данных имела набор функций, которые извлекали данные, и они зависели от соединения с базой данных. Кроме того, я хотел получить очевидное отличие, к какой базе данных относится функция. Для меня было целесообразно создать объект для каждой базы данных. Конструкторы выполнили предварительную работу по настройке соединений.
Внутри каждого объекта вещи в значительной степени процедурные. Например, каждый класс имеет функцию getEmployeeName(), которая возвращает строку. На этом этапе я не вижу необходимости создавать объект Employee и получать имя как свойство. Объект может иметь больше смысла, если мне нужно было бы получить несколько данных о сотруднике, но для небольшого количества вещей, в которых я нуждался, это не выглядело достойным.
Стоимость. Объясните, как правильно использовать функции языка, чтобы программное обеспечение было написано и поддерживалось для более низкой стоимости. (например, Java Foo.getBar() вместо foo- > bar, который часто встречается в коде C/С++).
Иначе почему мы это делаем?
Я нашел книгу Концепции, методы и модели компьютерного программирования, чтобы быть очень полезной в понимании и предоставлении мне лексики для обсуждения различия в языковых парадигмах. Книга на самом деле не охватывает Java или С# как 00-языки, а скорее концепции разных парадигм. Если бы я преподавал OO, я бы начал с того, что показал различия в парадигмах, затем медленно разницу в 00-языках, практический материал, который они могут сами по себе делать, выполняя курсовые работы/проекты.
Когда я перешел от процедурного к объектно-ориентированному, первое, что я сделал, было ознакомлено со статической областью.
Java - хороший язык для начала выполнения OO, потому что он пытается оставаться верным ко всем различным парадигмам OO.
Процедурный программист будет искать такие вещи, как точки входа и выхода из программы, и как только они смогут концептуализировать, что статическая область в классе throwaway является для них наиболее знакомой, знание будет расцветать оттуда.
Я помню момент лампочки довольно ярко. Помогите им понять ключевые слова abstract, instance, static, methods, и вы, вероятно, собираетесь предоставить им инструменты, чтобы лучше двигаться вперед.