Прошло много лет с тех пор, как я подумал об этом, но вскоре я тренирую некоторых настоящих юниоров и должен объяснить, что представляет собой объект для тех, кто не знает, что это такое.
Основываясь на том, что вы используете в реальном мире, каковы ключевые моменты объектов, которые я должен сосредоточить на объяснении. Например:
Когда я изучал ООП, я был озадачен всеми этими метафорами "автомобиль/животное/все". Они мне совсем не помогли. Затем кто-то сказал, что класс/объект - это просто набор переменных (членов класса) и функции для их решения (методы), что на самом деле верно. Это было так просто!
Использование всех этих популярных метафор - всего лишь вводящие в заблуждение людей, ИМХО. У автомобилей не так много общего с ООП. Легко понять эти метафоры, когда вы уже знаете, что они означают, но пытаясь начать с них... нет.
Мне нравится оригинальная метафора, используемая Аланом Кей, который придумал "объектно-ориентированное программирование": объекты похожи на ячейки в теле. Каждый из них запрограммирован своим собственным поведением и общается путем передачи сообщений друг другу, на которые они снова отвечают своим собственным внутренне определенным поведением. Ни одна клетка не знает, что внутри другого - они просто знают, как справляться со своими задачами и общаться друг с другом.
Если вы хотите что-то действительно полезное, не забудьте объяснить, почему. Это концепция, которая, как представляется, часто упускается - почему это полезно...
Метафоры животного/автомобиля существуют, чтобы объяснить философию объектно-ориентированного проектирования, что гораздо важнее понять, чем просто реализация.
Если вы пропустите метафоры и начните с просто "это просто переменные и функции для борьбы с ними", вы не получите описания ответственности. Я постоянно занимаюсь разработчиками, которые не учитывают ответственность за класс (см. CRC-карты), но вместо этого помещают данные и методы в классы, где бы они ни были редактирование в это время.
Вы также пропустите "расскажите, не спрашивайте". Здесь хорошо работает животная метафора. В ОО я говорю собаке убираться. Я не спрашиваю его, как он это сделает, потому что это черный ящик, который я не хочу видеть внутри. Собака знает, поэтому мне не нужно.
Просто не забудьте научить своих учеников, что это всего лишь метафоры, а не настоящая вещь. "Совершенный шторм" в "ипотечном расплавлении" на самом деле не предполагает ни штормов, ни чего-либо, что плавится.
Я бы пошел от уровней доступа и инкапсуляции и ушел оттуда. Инкапсуляция - это достаточно простая концепция для понимания и имеет некоторые явные преимущества. Оттуда вы легко можете говорить об абстракции, наследовании и полиморфизме.
Будучи студентом, я обнаружил, что Encapsulation является хорошей концепцией привязки в довольно абстрактной области.
Я бы взял определение Грэди Буча: Объект - это объект, который имеет состояние, поведение и идентификацию. Членские переменные вносят вклад в состояние; Методы способствуют Поведению, а некоторые уникальные атрибуты способствуют идентичности. Например, электронная почта может быть атрибут identity для объекта Person.
Одна из вещей, которую я нахожу многими людьми в замешательстве в ООП, - это фактические экземпляры объекта. То, что у вас есть способность создавать несколько экземпляров одного и того же класса, независимо друг от друга, похоже, увлекает умы людей. Если вы собираетесь использовать обычную аналогию с "физическим объектом", убедитесь, что вы говорите о том, как вы можете иметь несколько экземпляров указанных объектов и как они могут взаимодействовать друг с другом, а также с самими собой.
Например, возьмите классический пример "автомобиль". Теперь у вас есть программа для водителя "дорога", в которой есть функция "carCrash (Car car1, Car car2)". Объясните, как объекты взаимодействуют друг с другом.
Единственная проблема с подобными аналогиями заключается в том, что, по моему опыту, они, как правило, ломаются, когда вы начинаете говорить о статических переменных/функциях. Я предполагаю, что я пытаюсь сказать, что никакая аналогия не идеальна, поэтому старайтесь не слишком полагаться на них.
Как всегда, это действительно зависит от языка, из которого они происходят. Не каждый язык реализует парадигмы OO одинаково, иногда можно использовать OO-подход на языке, который не является строго OO вообще.
Как правило, важны уровни доступа. Почему свойства должны быть приватными? Какой смысл иметь геттеры и сеттеры? Это хорошее место для контраста объектов с коллекциями, такими как карты или массивы (даже если они могут быть реализованы как объекты, а не примитивы).
Наследование и полиморфизм должны идти рука об руку. Это вопрос абстракции. Объяснение различия между абстрактными базовыми классами и интерфейсами, вероятно, скорее связано с языковой проблемой - некоторые языки допускают множественное наследование, а другие допускают только несколько интерфейсов.
Инкапсуляция довольно проста, если вы определили уровни доступа. Опять же, в зависимости от языка, который вы, возможно, захотите объяснить внутренними классами и т.д., Абстрагируйте идею OO еще больше с анонимными классами.
Я нахожу, что лучше всего работает, это начать с чего-то знакомого: связанные функции и переменные. Изучение того, что должно быть объектом и каким объектом должно принадлежать свойство или метод, является жестким, поэтому начинайте с ясных случаев.
Обработчик базы данных может быть хорошим примером или, может быть, электронной почтой (создавать новое электронное письмо, устанавливать его заголовки и содержимое, прикреплять файлы и отправлять их - довольно простые и знакомые даже для не-программистов, но прекрасный пример для мышление с точки зрения объектов (электронная почта, контакты, возможно, даже почтовые ящики, серверы), методы (создавать, отправлять, прикреплять, устанавливать) и свойства (заголовки, содержимое, вложения)).
Что важно: даже если у ваших учеников есть некоторый (не-OO) фон программирования, настройка на ООП - это процесс, но "получить его" часто нет. Я слышал, что многие люди описывают это как внезапное событие, а не плавный переход. Конечно, "калибровка" - это долгосрочный процесс: вам нужно выяснить, когда имеет смысл создавать новые классы, и когда достаточно нескольких временных переменных, функций массива или полезности (в зависимости от вашего языка), но это необходимо практика, а не обучение.
Я предпочитаю подход, используемый в "Объектно-ориентированном дизайне и шаблонах" Hortsmann. Если я правильно помню, подход заключался в том, чтобы прочитать инструкцию по проблеме и идентифицировать объекты, их методы, отношения и другие компоненты, используя простой шаблон. Например, объект является существительным, поэтому все существительные будут объектами-кандидатами.
Сама книга настоятельно рекомендуется. После определения того, что представляет собой объект, он использует некоторые четко определенные и простые примеры для обсуждения наследования, интерфейсов и многих шаблонов проектирования, таких как singleton.
Ха-ха... поэтому я думаю, я действительно предлагаю вам позволить кому-то еще сделать это... автор (ity).
Если бы я пытался объяснить классы и объекты кому-либо, совершенно незнакомому с программированием, я бы, вероятно, использовал что-то в следующих строках:
Класс - это всего лишь "рецепт для вещи", класс состоит из разных типов "ингредиентов", которые имеют разные характеристики (т.е. POD и функции/методы).
Таким образом, он содержит только описания макета (строительных блоков) и функциональности.
Ингредиенты могут быть разных типов: "данные" в том, что они содержат фактические поля данных (думаю, что факты хранятся в переменных/полях) и "действие", поскольку они содержат конкретные методы , чтобы сделать что-то.
Некоторые ингредиенты могут быть секретными, вы можете не захотеть делиться всеми ингредиентами, или вы можете не хотеть делиться некоторыми конкретными способами делать определенные вещи с рецептом (инкапсуляция).
Итак, у вас, как у повара, есть возможность ограничить доступ к ингредиентам, чтобы пользователи вашего рецепта придерживались вашего рецепта и просто использовали "заранее подготовленные" шаги (методы) для выполнения тех действий, которые вы предоставляете (без они обязательно знают, что это такое):
Некоторые ингредиенты могут быть только внутренне видимыми ( частный доступ), потому что они действительно имеют отношение к этому конкретному экземпляру/манифестации рецепта/класса, в то время как другие могут также быть доступные из рецептов, основанных на этом рецепте (думаю, настройки), которые вытекают из него ( защищенный доступ).
И тогда есть ингредиенты, которые должны быть в целом видимыми и доступными для всех пользователей рецепта (общедоступный), поскольку они составляют "интерфейс" или "интерфейс" конечного продукта (они надевают 'обязательно нужно знать о внутренних элементах/материалах с низким уровнем реализации).
Как только класс фактически используется для реализации определенного рецепта, создается новый объект (экземпляр класса создается): шоколадный торт - это всего лишь одно из проявлений/вариантов рецепта шоколадного торта. Могут быть много других версий, использующих один и тот же "рецепт".
Если вам нужно было объединить несколько рецептов (например, шоколадный торт и лимонный торт), вы можете создать новый рецепт, который получается из обоих рецептов, в основном создавая совершенно новый рецепт, который разделяет характеристики оригинальных рецептов (multiple наследование).
Основывая новые рецепты на существующих, используя наследование, изменения в оригинальном рецепте могут быть напрямую импортированы в новый рецепт. Точно так же, имея общий рецепт предка (тип/суперкласс), означает, что его самые свойства (поля и методы) можно ожидать во всех подклассах (унаследованные/дочерние рецепты), другими словами, общий "рецепт шоколадного торта" может быть используется для создания двух новых специализированных версий шоколадного торта: "белый шоколадный торт" и "темный шоколадный торт", где цвет шоколада просто становится атрибутом, который может быть сконфигурирован с использованием специального метода шоколадного торта, такого как "setChocolateColor()",.
Если вы хотите, чтобы ваш рецепт позволял новым рецептам переопределять некоторые компоненты вашего рецепта, вы можете предоставить шаблонные действия (методы), которые можно индивидуально переопределить (виртуальное наследование).
объекты (обычно) имеют состояние, поведение и идентичность.
Основные принципы программирования o-o - это инкапсуляция, наследование и полиморфизм.
Основные принципы проектирования o-o приведены здесь: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Я бы попытался начать с фактического кода. Надеюсь, они хоть немного знакомы с каким-то языком. Напишите простую программу без использования каких-либо классов или дизайна OO вообще, а затем покажите, как ее можно упростить или упростить для поддержания или что-то еще, если вы повторите ее с помощью классов.
Хорошим примером может быть что-то, где есть несколько функций, которые используют один и тот же набор переменных. Например (это только первый пример, о котором я мог думать. Вероятно, вы могли бы подумать о гораздо лучших - надеюсь, что-то, что не кажется слишком изобретенным и похоже на то, что вы на самом деле пишете для реального проекта):
void printContactInfo(String name, String address, String phoneNumber) {
System.out.println(name + " lives at " + address + " and his/her phone number is + "phoneNumber");
}
Вы пишете код выше, затем в какой-то момент позже вы решите, что хотите добавить адрес электронной почты и имя пользователя. Или вы имеете дело с двумя разными людьми. Вы могли бы легко получить громоздкие функции, которые принимают несколько аргументов, или имеют два миллиона переменных для отслеживания. Или вы можете написать класс Person, и вы просто вызываете:
Person someguy = new Person("MatrixFrog", "123 Notareal Street", "555 5555");
someguy.printContactInfo();
Опять же, возможно, не лучший пример. И я согласен с безумством в том, что эти маленькие "автомобильные" и "личные" примеры не всегда велики. Но я думаю, что если вы представили пример как решение реальной проблемы, возникающей при написании кода, это может быть более ясным.
То же самое с наследованием. Идея основана на реальном понимании того, что "X - это определенный тип Y", но причина, по которой мы это делаем, - сделать код более удобным для чтения и записи. Я не думаю, что я действительно понял наследование до тех пор, пока в первый раз не обнаружил, что я пишу два класса, имеющих много общего, и думаю: "Подождите, у них много одинаковых свойств. Возможно, я должен поместить свои общие свойства в суперкласс!"
Иногда начинающим понятно, как объекты относятся к выполнению программы. ( "Хорошо, у меня есть объект Person, который я могу создать как" Джерри ", но где я могу выполнить экземпляр? Что создает Джерри? Хорошо, тогда что это создает? Где все это начинается?" )
Попробуйте аналогию с вселенной. Типы в вашей программе представляют на разных уровнях абстракции все возможные объекты, которые могут существовать во Вселенной. Не забудьте показать им большой взрыв (точка входа в программу)! Это также покажет им, почему глобальные переменные в ООП не имеют смысла. Затем вы можете погрузиться в принципы ООП.
Для новичков: объект подобен существительному. Если вы в классе, у вас есть столы, студенты, преподаватели, проектор и т.д. У каждого есть свои характерные и некоторые общие черты.
Итак, если мы хотим написать программу, которая будет вести себя так же, как класс, нам нужно воссоздать все эти "существительные" в коде. Каждый может делать вещи (student:: listen()), и они могут взаимодействовать друг с другом (student:: search (new Desk()))
Когда мы определили все правила и поведение (например, наши классы/интерфейсы), мы отложим их в программе. для (i = 0; я < 30; я ++) {class.Add(новый ученик())} и т.д.
Мой опыт как самостоятельного ученика состоит в том, что я ввел в голову массу проблем с концепцией объекта, сопоставленной с "реальной сущностью", например, животными и автомобилями и т.д. Он формирует вашу голову, желая найти реалистичную (как в "реальном мире" ) таксономию в ваших бизнес-объектах, даже когда ее нет, и она смущает вас в поиске нереалистичной таксономической классификации, которая вместо этого полезна для реального проектирования ОО (например, дизайн узоры). Наконец, это подталкивает вас к тому, что вы окажетесь в одной таксономии "реального мира", даже если другой "менее реальный мир" может существовать, и они лучше.
В любой книге ООП вы обнаружите, что квадрат является своего рода прямоугольником, и поэтому квадрат представлен как унаследованный прямоугольником, но мы знаем, что этот подход глубоко ошибочен (я прочитал статью об этом, не помните, где, но вы можете найти "хрупкую проблему базового класса" в google). Кроме того, на некоторых языках программирования вам не нужна таксономия OO для наследования интерфейса (см. мой пост в этом отношении).
Итак, мое предложение: представить его, но будьте очень осторожны, как далеко вы идете, и в конечном итоге сразу переключайтесь с примеров "автомобиль и животные" на менее приятное, чтобы представить таксономию. Вы можете глубоко испортить свое понимание, если вы слишком далеко продвигаетесь.
Stick with Booch definition: Объект имеет состояние, демонстрирует определенное поведение и имеет уникальный идентификатор. Я заметил, что другие уже опубликовали это, но люди комментировали некоторые объекты, которые не нуждаются в состоянии, поведении или идентичности, с которыми я не согласен. Объект имеет состояние в том смысле, что определенный программист определил объем памяти для него, поведение в том смысле, что оно может реагировать на отправленные на него сообщения, и идентичность в том смысле, что ему может быть назначен идентификатор. Что на самом деле звучит так же, как объяснение Кей многих небольших специализированных компьютеров, общающихся друг с другом.
Я также согласен с несколькими сообщениями, в которых впервые рассматриваются концепции процедурного программирования, поскольку работа в объектно-ориентированной программе все еще выполняется на уровне процедуры. Разница заключается в уровне абстракции, на котором программист может написать программу. В объектно-ориентированном программировании программирование на более высоком уровне абстракции - это способность программиста создавать концепции, которые охватывают состояние и поведение в любой комбинации, явные. Это, очевидно, требует понимания того, как реализовать концепции, используя состояние и поведение.
Следующей основной концепцией, которую я бы рассмотрел, является обобщение. Объект, выбирающий, какое поведение вызывать в ответ на отправку сообщения во время выполнения, позволяет обобщение. Обобщение происходит, когда программист скрывает детали того, как выполнить аналогичную концепцию двумя разными способами за одним единообразным сообщением.
Отсюда я перейду к инкапсуляции, наследованию и полиморфизму. И оттуда к более высоким уровням понятий. Я просто чувствую, что держать все сосредоточенное на том, как эти понятия помогают решать проблемы, важно для их сохранения.
Используйте примеры реальной жизни.
уровни доступа: И ваша мама не может тронуть ваших рядовых, но ваши друзья могут.
Мне нравится пример "Vehicle". Многие вещи могут быть транспортными средствами (абстрактным классом), но все они имеют что-то общее - они могут двигаться от а до некоторой скорости. Тогда могут быть разные классы транспортных средств: движущиеся транспортные средства, некоторые движущиеся в воде, некоторые в воздухе.
Итак, у вас есть еще один уровень абстракции - все транспортные средства в воздухе, например, нуждаются в высоте.
Я думаю, вы получите картину. Это объясняет большинство пунктов, которые вы указали выше.
Я предпочитаю использовать реальные примеры, с которыми вы действительно можете взаимодействовать: посудомоечная машина, автомобиль,...
У этих вещей также есть очень строгий интерфейс: автомобиль (в Европе:)) имеет педаль акселератора, перерыв и сцепление. Вы можете запросить текущую скорость.
Инкапсуляция: не нужно знать, как работает двигатель, если вы знаете интерфейс. Хорошо, что вам тоже не нужно самостоятельно менять двигатель.
Полиморфизм: вы можете управлять Lada и Porche, используя тот же интерфейс. Это означает, что вы полиморфный драйвер:).
Примечание. Мне потребовались годы, чтобы отличить концепцию интерфейса от наследования. Я бы сказал: оставь наследование на некоторое время: большая часть повторного использования кода времени достигается лучше по составу (хотя это и другое обсуждение).
Начнем с того, что означает Object-Oriented-Design...
- Это означает, что вы принимаете реальную ситуацию, которую хотите моделировать, используя программное обеспечение и копируя свою модель в модели программного обеспечения.
Каждый объект в реальной ситуации (тот, который существует, даже если не было программного обеспечения) получает представителя в разработке программного обеспечения - объекта. (Абстракция)
Каждый тип сущности является классом, каждый объект того же типа является объектом того же типа.
* Приведите пример из поля, которое интересует ваших учеников и продолжит с тем же примером. - Попробуй сделать это забавным.
Каждый объект должен моделировать только один объект и весь объект, если вы меняете один объект, он не должен влиять на другой. (Инкапсуляция)
Далее вы думаете о связях между сущностями, является одним из видов другого (наследование), является частью другого (композиции), может входить и выходить из другого (агрегация).
Далее вы размышляете о том, что сущности делают (методы) и как их определить (свойства/поля).
Теперь возьмем пример для наследования из приведенного выше примера и объясним полиморфизм - вы можете сделать то же самое, что можете в общем типе, как можете, для любого определенного типа, который наследует его, и вы можете задать каждый конкретный тип сделайте то, что вы можете попросить, чтобы общий тип делал, но они могут делать это так, как они хотят (переопределяют).
Следующие интерфейсы, здесь, возможно, используют животных - не у всех животных есть хвосты, а у некоторых. Вы хотите моделировать человека, собаку, кошку, паука и динозавра. Все (или были) животные, но общий тип - животное не может помахать своим хвостом, a. потому что нет такого понятия, как родовое животное (оно абстрактно) b. потому что не животные могут WagTail(). Тем не менее, все те, которые могут WagTail() могут реализовать интерфейс IWagTailable.
Уровни доступа:
если что-то является частью описания сущностей или известных действий (если оно находится в его контракте) - оно общедоступно.
Если объект хранит некоторую информацию, о которой только нужно знать или о ней известно, или о чем-то, о чем никто не знает, - это частный.
Если не всем известно об этом, но его наследникам разрешено знать об этом - он защищен.
Может быть, зайдите в конструкторы (как инициализировать определения объектов) и деструкторы (освобождая хранимые/хранимые файлы/файлы).
Возможно, также свойства - вроде подобных полей, только вы можете ограничить доступ только для чтения, только для записи или даже сделать что-то при чтении или записи.
Я предпочитаю думать о муравьях - он дает зрителям что-то "видеть", а вы "рассказываете" слушателям. Сначала сосредоточьтесь на ПОЧЕМУ для каждой части, чтобы избежать появления стекловидных глаз.
Ant происходит от насекомого (наследование) Рабочий Ant, Queen Ant, Drone Ant все происходит от Ant (Наследование). Нет никакого общего "Ant", все муравьи происходят из производных классов Worker, Queen и т.д., Но все они имеют одинаковые базовые интерфейсы (методы) и свойства.
Рабочий Ant, Queen Ant, Drone Ant вытекает из Ant и, следовательно, демонстрирует ad-hoc-полиморфизм, где все они происходят из одного и того же класса Ant и exibit-подтипирования полиморфизма (Inheritance) w43 > , эти муравьи являются подклассом класса Ant и наследуют 6 ног, 2 глаза, 3 сегмента тела и т.д. Ant - Свойства. Ant также имеет методы, методы ходьбы, просмотра и захвата класса Ant. Таким образом, применение импликации интерфейса более общего класса Ant (Полиморфизм) со свойствами и методами базового класса Ant, но каждый подкласс определяет, как он реализует их.
У рабочих-муравьев разные действия и поведение. Они собирают еду, защищают колонию, копают туннели, ухаживают за королевой Ant и т.д., Но все же имеют базовые атрибуты Ant (интерфейс). Челюсти используются в каждом поведении - полиморфная функция, которая НЕ является полиморфизмом сама по себе, и поэтому вы получаете представление о перегрузке метода для различного использования челюстей - каждый метод имеет базовое сходство (челюсти, захват), но используются разные типы объектов - захватить грязь, схватить другую Ant, схватить пищу, схватить макарону с королевой, схватить врага. Это показывает ПОЧЕМУ методы перегрузки, - области специализации в зависимости от того, что захвачено - личинка (молодые муравьи) и пища обрабатываются мягко и иначе, чем враг, где мы хотим разорвать их.
Каждый рабочий Ant - это экземпляр Ant, отдельный, но с похожим поведением и другой задачей/состоянием в заданное время, поэтому с учетом заданий они могут быть на разных потоках. Если один Ant на миссии по сбору пищи (нить) умирает, другие муравьи продолжают искать пищу, поскольку они не зависят от выживших мертвых муравьев.
Каждый Ant имеет доступ и способность манипулировать своими собственными атрибутами, ногами, глазами и т.д., но не манипулировать другими глазами и ногами муравьев (Уровни доступа).
Ant Колония - общее пространство имен для Ant, поэтому Queen Ant и Worker Ant могут принадлежать к пространству имен колоний Ant, а рабочие муравьи имеют доступ к Queen Ant но ничего снаружи (защищено)
Королева-муравьи никогда не выходят наружу - (Уровни доступа)
Каждый Ant имеет доступ и способность манипулировать своими атрибутами, ногами, глазами и т.д., но не манипулировать другими глазами и ногами муравьев (Уровни доступа). Теперь этот Ant знает, где его ноги, где он смотрит, те, которые инкапсулированы в его экземпляр. Акт инкапсуляции в некоторой степени создает абстракцию здесь.
Используя концепцию инкапсуляции, мы можем Аннотация и, таким образом, мы можем отправить Worker Ant, чтобы получить еду, но нам не нужно заботиться о том, как Ant получает пищу, только то, что она возвращается с пищей, мы выделили детали активности из результата.
Вы можете использовать примеры на выбранном языке для своей аудитории. Если это помогает одному человеку, я доволен:). Надеюсь, я не смутил себя:)
По моему собственному опыту, я думаю, что идея объекта или класса, просто являющегося экземпляром вещи или описания вещи, может быть вполне адекватной для первоначальной абстракции. То, что есть, т.е. Члены и/или свойства, и может делать, то есть методы, - следующий уровень добавляемых вещей. Затем появляются идеи наследования, абстракции, инкапсуляции и полиморфизма как способы округлить первоначальный подход к моделированию, который пытается сделать ООП. Я пришел в ООП из процедурного кодирования, поэтому идея настраиваемых типов переменных создает множество различных идей, которые можно изучить.
Я бы использовал один пример для всего, чтобы создать концепцию, а не перепрыгивать через несвязанные примеры.
Этот магический пример будет GUI.
GUI сделал большой смысл, когда я понял ООП после большой борьбы.
Окно - это объект. кнопка - не что иное, как причудливый способ сказать прямоугольник, нарисованный особым образом (абстракция). У окна есть кнопки. Гиперссылка - это кнопка. каждая Clickable вещь на моем экране - это кнопка (Интерфейсы). Все кнопки при нажатии идут на переполнение стека (наследование). За исключением одной кнопки, которая относится к ошибке сервера (полиморфизм).
И сложная часть, "Инкапсуляция", которая не что иное, как причудливый способ спасти программиста от отладки:)
В конце я хотел бы подчеркнуть, что ООП - это не конец света, если не имеет смысла думать о чем-то как об объекте, то это не объект. Поскольку я видел программиста, пытающегося построить класс mergesort: D
Спасибо,
ИМХО, мы должны сначала заинтересовать их ООП перед бомбардировкой их всеми концепциями ООП. Чтобы привлечь их к ООП, объяснение всех концепций ООП или показ примеров кошек и собак не будет работать. Вы должны показать им преимущества, сравнивая проблему, решающую ООП и способ без ООП. Удостоверьтесь, что вы сначала решили проблему не ООП, выделите недостатки, используйте одну из концепций ООП для ее решения. Вероятно, он может использовать только одну концепцию ООП, но если вы сможете заставить их почувствовать преимущество, которое он придерживается по другому методу, они сами будут стремиться исследовать больше ООП. После этого вам просто нужно указать их в правильном направлении. После того, как они знакомы с концепциями, назовите их к книгам с шаблонами дизайна, например "Нарисуйте первые шаблоны дизайна".
Я попытался бы сравнить парадигму процедурного программирования с ООП. Даже если ваши ученики совершенно не знакомы с программированием, я бы показал им несколько примеров с "примитивами", а затем с примерами с объектами. Я бы указал разницу между переменной примитивного типа и объектом класса в том, что тип объекта может содержать несколько переменных (членов). Конечно, в этот момент вы должны были упомянуть о функциях, если они еще не знали их. Фактически, в первом уроке я хотел бы объяснить основные концепции процедурного программирования (переменные, типы, функции), которые являются основой для фундаментальных понятий ООП. В конце концов, ООП - это просто оболочка для процедурного программирования сама по себе.
После урока, наряду с объяснением членов объекта, вы должны также объяснить методы. Для "действительно младших учеников" я бы сосредоточился на уровнях доступа, инкапсуляции и, наконец, наследования.
Примеры реального мира, такие как автомобиль и т.д., могут использоваться, чтобы показать, почему хорошо иметь объекты, но после того, как вы подвергли своих учеников основным концепциям программирования. Для ваших более талантливых учеников я бы дал подсказки, например, что объект является просто неявным аргументом для его методов или что элемент объекта похож на ограниченную глобальную переменную или что объект похож на замыкание и т.д. ( это зависит, конечно, от ваших учеников, и вам нужно не путать их, поэтому этот последний совет не обязательно, конечно:-)).
Я могу начать с анонимных типов или что-то вроде JSON, чтобы продемонстрировать, что объекты - это просто коллекции свойств. Расскажите о сплоченности.
Что, если нам нужна куча этих объектов? Классы/Конструкторы/экземпляры.
Как насчет функциональности? Методы.
Затем продемонстрируйте проблемы, возникающие из-за отсутствия инкапсуляции. Покажите, как getters/setters/private fields облегчают проблему (возможно, перейдите на типизированный язык, если вы используете JSON)...
Затем покажите, как наследование позволяет повторное использование кода - возможно, покажите образец наследования, фактически перепечатав (с помощью клавиатуры) функциональность, чтобы продемонстрировать, что это за боль. Покажите, что вы можете что-то изменить в одном авторитетном месте, когда все хорошо спроектировано.
Затем ввести полиморфизм - потому что наследование иногда бывает недостаточным. Включите здесь интерфейсы.
Попробуйте использовать реальные примеры - либо с базы кода, на которой они будут работать, либо из вашего собственного портфолио. По мере того, как вы идете, продемонстрируйте рефакторинг и другие хорошие практики. "Эй, я повторяю этот шаблон - я должен каким-то образом его консолидировать".
этот вопрос интересен... и очень сложный... потому что он зависит от языка, который вы используете...
возьмите objective-c: объект имеет это переменные, доступные только из внутри и методы, такие как accessors... objective-c на самом деле отправляет сообщения между объекты... которые дают определенную стоимость, но позволяет много прохладных вещи, такие как прокси, макет объектов, профилирование, АОП и т.д.... в objective-c, класс является объектом... objective-c не имеет понятия уровней доступа...
взять PHP... там, классы не объекты... объекты имеют переменные и методы... и это полностью несогласованный...:)... как плохой пример...
возьмите Ruby... там, все полностью динамический... объект имеет его переменные, только видимые из внутри и классе, определяя его методы... вы можете изменить этот класс во время выполнения или даже, вы можете назначить другой класс для этого самого объекта ... фанки... а также, в рубине, операторы - это методы объектов ... у вас невероятный язык Конструкции, подобные блокам...
возьмите ECMA- Script (например, JavaScript)... здесь все есть объект... функции являются объектами первого класса... объектом имеет набор свойств (полностью динамический), некоторые из которых могут быть функций, действующих как объект методы... вы можете принять метод одного объекта и применить его к другой вместо этого (необязательно имеют смысл, но это возможно)... любая функция может быть использована для создать новый объект... и так на... ECMA- Script не имеет концепции уровней доступа, но вы можете скрыть данные с помощью закрытий, если необходимо... ECMA- Script не знать классы... но наследование достигнутый на основе его прототипа природа...
Я мог бы продолжить... но вы видите мою точку зрения, я думаю... многие языки реализуют только части всех вещей, которые наиболее понимают как ООП и подчеркивают разные вещи... иногда это слабость, иногда мощная... также семантика, то, что есть объект, и какой метод, ОЧЕНЬ другой... чтобы не путать ваших учеников, вы действительно должны придерживаться одного языка или языков, имеющих точно та же семантика, когда речь идет об объектах, и описание того, что представляет собой объект... в противном случае они никогда не поймут вашу модель... как только они обернутся вокруг, вы можете показать, как ООП смотрит на других языках...
Я думаю, вы должны взять JavaScript или Ruby (хотя я думаю, что JavaScript лучше, а затем перейти к ActionScript 2, иметь его типизированную версию и классы, интерфейсы и т.д.... или начать с ActionScript 2 напрямую), чтобы показать концепции ООП, поскольку они очень радикальные, понятные и простые... или, возможно, другие языки сценариев...
нельзя забывать, что он объектно-ориентированный, а не классно-ориентированное программирование... выбор языка, который не требует классов для создания объектов, кажется хорошей идеей...
используйте язык, который является последовательным и сохраняет код коротким и кратким... старайтесь избегать ситуаций, когда у вас есть n строк кода, которые являются обязательными, но на самом деле у вас нет времени их объяснять..
на мой взгляд, сначала познакомить людей с ООП, это хорошее решение... ООП о моделировании... чем выше язык, тем больше он учит абстрактному мышлению... начиная с процедурных языков, где вы поддерживаете состояния в тоннах переменных, разбросанных по вашей программе, нехорошо... для людей, которые действительно изучали процедурное программирование, требуется много времени, чтобы перейти к ООП...
ну, это было немного больше, чем я на самом деле собирался писать... надеюсь, что это поможет хотя бы...:)
Greetz
back2dos