Как объяснить объект?

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

У этих вещей также очень строгий интерфейс: Автомобиль (в Европе :)) имеет педаль акселератора, тормоз и сцепление. Вы можете запросить текущую скорость.

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

Полиморфизм: вы можете управлять Lada и Porche, используя один и тот же интерфейс. Это означает, что вы полиморфный драйвер :).

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

Используйте примеры из реальной жизни.

• Животное (интерфейс)
• Млекопитающее (абстрактный класс)
• Собака (класс)
• Ваша собака (экземпляр объекта)

уровни доступа : И твоя мама не может трогать твои половые органы, а твои друзья могут.

I like the "Vehicle" example. Many things can be vehicles (abstract class), but they all have something in common - they can move from a to be at some speed. Then there can be different classes of vehicles: gound vehicles, some moving in water, some in the air.

So you have another level of abstraction - all vehicles in the air for example need an altitude member.

I guess you get the picture. This explains most of the points you've given above.

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

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

Ха-ха ... так что я думаю, я действительно предлагаю вам позволить кому-то другому сделать это .. .. автор (его).

Как всегда, это действительно зависит от того, на каком языке они исходят. Не каждый язык реализует объектно-ориентированные парадигмы одинаково, иногда можно использовать объектно-ориентированный подход на языке, который вообще не является объектно-ориентированным.

Как правило, важно упомянуть уровни доступа. Почему собственность обычно должна быть частной? Какой смысл иметь геттеры и сеттеры? Это хорошее место для сопоставления объектов с коллекциями, такими как карты или массивы (даже если они могут быть реализованы как объекты, а не примитивы).

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

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

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

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

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

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

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

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

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

набор) и свойства (заголовки, контент, вложения)).

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

набор) и свойства (заголовки, контент, вложения)).

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

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

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

Я бы пошел по определению Грэди Буча: Объект - это объект, который имеет состояние, поведение и идентичность. Переменные-члены вносят вклад в состояние; Методы способствуют поведению, а некоторые уникальные атрибуты способствуют идентификации. Например, электронная почта может быть Атрибут identity для объекта Person.

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

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

Будучи студентом, я обнаружил, что инкапсуляция является хорошей концепцией привязки в довольно абстрактной области.

Если вам нужно что-то действительно полезное, не забудьте объяснить почему. Эту концепцию часто упускают - почему это полезно ...

Начните с объяснения, что означает объектно-ориентированный дизайн ...

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

Каждая сущность в реальной ситуации (существующей, даже если не было программного обеспечения) получает представителя в проекте программного обеспечения - объект. (Абстракция)

Каждый вид сущности является классом, каждая сущность одного и того же типа является объектом одного и того же типа.

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

Каждый объект должен моделировать только одну сущность и эту сущность целиком, если вы меняете один объект, это не должно влиять на другой. (Инкапсуляция)

Затем вы думаете об отношениях между сущностями, Вы хотите смоделировать человека, собаку, кошку, паука и динозавра. Все являются (или были) животными, но общий тип - животное не может вилять хвостом, a. потому что не существует такого понятия, как родовое животное (оно абстрактное) b. потому что не животные могут WagTail (). Однако все, кто может использовать WagTail (), могут реализовать интерфейс IWagTailable.

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

Может быть, проникнуть в конструкторы (как инициализировать определения объекта) и деструкторы (освободить память / файловые дескрипторы / соединения, которые он держит ).

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

Я предпочитаю думать о муравьях - они дают визуальным ученикам что-то «видеть», а вы «рассказываете» слушателям. Сначала сосредоточьтесь на ПОЧЕМУ для каждой части, чтобы избежать остекленевших глаз.

Муравей происходит от Насекомого (Наследование) Рабочий муравей, королева муравьев, трутень-муравей - все происходят от муравья (наследование). Не существует универсального «муравья», все муравьи происходят от производных классов Worker, Queen и т. Д., Но все они имеют один и тот же базовый интерфейс - действия (методы) и свойства.

Worker Ant, Queen Ant, Drone Ant являются производными от Ant и, таким образом, демонстрируют специальный полиморфизм, где все они происходят от одного и того же класса Ant, и проявляют полиморфизм подтипов (наследование) класса Ant, эти муравьи являются подклассом класса Ant и наследуют 6 ног, 2 глаза, 3 сегмента тела и т.д. Муравья - Свойства. У Ant также есть методы, возможность ходить, видеть и захватывать, как у класса Ant. Таким образом, приложение имплементации интерфейса более общего класса Ant (полиморфизм) со свойствами и методами базового класса Ant, но каждый подкласс определяет, как он их реализует.

Муравьи-рабочие имеют разные виды деятельности и поведение. Они собирают еду, защищают колонию, роют туннели, заботятся о королеве муравьев и т. Д., Но все еще имеют базовые атрибуты Муравья (интерфейс). Челюсти используются в каждом поведении - полиморфная функция, которая НЕ является полиморфизмом сама по себе, и, таким образом, вы получаете представление о перегрузке метода для различного использования челюстей - каждый метод имеет основное сходство (челюсти, захват), но используются разные типы объектов - схватить грязь, схватить другого муравья, схватить еду, забрать мусор у королевы, схватить врага Это показывает ПОЧЕМУ методов перегрузки - области специализации в зависимости от того, что схвачено - с личинкой (молодыми муравьями) и пищей обращаются осторожно и иначе, чем с врагом, которого мы хотим разорвать.

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

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

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

Королевы муравьев обычно никогда не выходят наружу - (Уровни доступа)

Каждый Муравей имеет доступ и способность манипулировать своими собственными атрибутами, ногами, глазами и так далее. но не манипулировать глазами и ногами других муравьев (уровни доступа). Теперь этот муравей знает, где его лапы, куда он смотрит, они инкапсулированы в его экземпляре. Акт инкапсуляции создает здесь до некоторой степени абстракцию.

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

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

I would try starting with actual code. Hopefully they're at least slightly familiar with some language. Write a simple program without using any classes or OO design at all, and then show how it can be made clearer or easier to maintain or whatever, if you redo it using classes.

A good example would probably be something where there are several functions that all use the same set of variables. For example (this is just the first example I could think of. You could probably think of much better ones -- hopefully something that doesn't seem too contrived and resembles something that you would actually write for a real-world project):

void printContactInfo(String name, String address, String phoneNumber) {
    System.out.println(name + " lives at " + address + " and his/her phone number is + "phoneNumber");
}

You write the code above, then at some point later, you decide that you'd also like to include the person's email address and username. Or you are dealing with two different people. You could easily end up with unwieldy functions that take several arguments, or have zillions of variables to keep track of. Or you could write a Person class, and you'd just call:

Person someguy = new Person("MatrixFrog", "123 Notareal Street", "555 5555");
someguy.printContactInfo();

Again, probably not the best example. And I do agree with mad-j that these little "car" and "person" examples aren't always great. But I think if you presented the example as a solution to an actual problem that comes up while writing code, it might be clearer.

Same thing with inheritance. The idea is based on the real-world understanding that "An X is a certain type of Y" but the reason we do it is to make code easier to read and write. I don't think I really understood inheritance until the first time I found myself writing two classes with a lot in common, and thinking, "Wait. These have a lot of the same properties. Maybe I should put their common properties into a superclass!"

объекты (обычно) имеют состояние, поведение и идентичность.

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

основные принципы проектирования находятся здесь: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

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

Если вы пропустите метафоры и начните с того, что «это просто переменные и функции, с которыми можно справиться», вы упускаете какое-либо описание ответственности. Я постоянно имею дело с разработчиками, которые не принимают во внимание классовую ответственность (см. CRC Cards ), но вместо этого помещают данные и методы в классы, где бы они ни редактировались в то время.

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

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

Потому что это согласованно.

Существуют такие методы, как:

[NSDictionary dictionary]
[NSArray array]

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

А удобные методы совместимы с методами init и initWith… .

вы можете не захотеть делиться всеми ингредиентами или вы можете не захотеть делиться некоторыми конкретными способами выполнения определенных действий с рецептом ( инкапсуляция ).

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

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

Кроме того, есть ингредиенты, которые должны быть видны и доступны всем пользователям рецепта ( public ), потому что они составляют «интерфейс» или «интерфейс» конечного продукта (они не t обязательно необходимо знать о внутреннем устройстве / низкоуровневой реализации).

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

Если вам нужно было объединить несколько рецептов (например, шоколадный торт и лимонный торт), вы можете создать новый рецепт, основанный на обоих рецептах, в основном создается совершенно новый рецепт, который разделяет характеристики исходных рецептов ( множественное наследование ).

Основывая новые рецепты на существующих с использованием наследования, изменения в исходном рецепте можно напрямую импортировать в новый рецепт блюда. Точно так же наличие общего рецепта предка (тип / суперкласс) означает, что его свойства (поля и методы) можно ожидать во всех подклассах (унаследованные / дочерние рецепты), другими словами, общий «рецепт шоколадного торта» может быть используется для создания двух новых специализированных версий шоколадного торта: «белый шоколадный торт» и «темный шоколадный торт», где цвет шоколада просто становится атрибутом, который можно настроить с помощью специального метода шоколадного торта, такого как «setChocolateColor ()» .

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

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

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

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

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

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

Этим волшебным примером может быть графический интерфейс.

Графический интерфейс имел большой смысл когда я понял ООП после долгой борьбы.

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

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

В конце я бы подчеркнул, что ООП это не конец света, думайте о чем-то как об объекте, тогда это НЕ объект. Потому что я видел, как программист пытался создать класс сортировки слиянием: D

Спасибо,

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

Придерживайтесь определения Буча: Объект имеет состояние, демонстрирует четко определенное поведение и имеет уникальную идентичность. Я заметил, что другие уже опубликовали это, но люди оставляли комментарии относительно некоторых объектов, не нуждающихся в состоянии, поведении или идентичности, с которыми я не согласен. У объекта есть состояние в том смысле, что для него выделен определенный программистом объем памяти, поведение в том смысле, что он может реагировать на отправляемые ему сообщения, и идентичность в том смысле, что ему можно присвоить идентификатор. Что на самом деле очень похоже на объяснение Кей множества маленьких специализированных компьютеров, взаимодействующих друг с другом.

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

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

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

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

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

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

не нужна объектно-ориентированная таксономия для наследования интерфейсов (см. мой пост по этому поводу ).

Итак, мое предложение: представьте его, но будьте очень осторожны, как далеко вы зайдете, и в конечном итоге немедленно переключитесь с "автомобиль" и животные »примеры менее приятной для представления систематики. Вы можете серьезно исказить их понимание, если зайдете слишком далеко.

не нужна объектно-ориентированная таксономия для наследования интерфейсов (см. мой пост по этому поводу ).

Итак, мое предложение: представьте его, но будьте очень осторожны, как далеко вы зайдете, и в конечном итоге немедленно переключитесь с "автомобиль" и животные »примеры менее приятной для представления систематики. Вы можете серьезно исказить их понимание, если зайдете слишком далеко.

Для новичка: объект подобен существительному. Если вы находитесь в классе, то у вас есть парты, ученики, учитель, проектор и т. Д. У каждого есть свои характеристики и некоторые общие черты.

Итак, если бы мы хотели написать программу, которая будет вести себя так же, как классная комната , нам нужно воссоздать все эти «существительные» в коде. Каждый может что-то делать (student :: listen ()), и они могут взаимодействовать друг с другом (student :: search (new Desk ()))

Когда мы определили все правила и поведения (т.е. написали наши классы / интерфейсы ), затем мы откладываем их в программе. for (i = 0; i <30; i ++) {class.Add (new Student ()))} и т. д.

Иногда новичкам трудно понять, как объекты связаны с выполнением программы. («Хорошо, у меня есть объект Person, который я могу создать как« Джерри », но где мне выполнить создание? Что создает Джерри? Хорошо, тогда что это создает? С чего все это начинается?»)

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

Я мог бы начать с анонимных типов или чего-то вроде JSON, чтобы продемонстрировать, что объекты - это просто наборы свойств. Поговорим о сплоченности.

Что, если нам нужна связка этих объектов? Классы / конструкторы / экземпляры.
А как насчет функциональности? Методы.

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

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

Затем введите полиморфизм - потому что наследования иногда недостаточно. Включите сюда интерфейсы.

Попробуйте использовать реальные примеры - либо из кода, над которым они будут работать, либо из вашего собственного портфолио. По ходу демонстрации рефакторинга и других передовых методов. "Привет,

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

• возьмите objective-c : объект имеет это переменные, доступные только из внутри и методы, такие как аксессоры ... objective-c на самом деле отправляет сообщения между объекты ... что дает определенная стоимость, но позволяет много крутых такие вещи, как прокси, имитация объектов, профилирование, АОП и так далее ... в objective-c, класс - это объект ... объект-c не имеет понятия уровней доступа ...

• возьмите PHP ... там классов нет объекты ... объекты имеют переменные и методы ... и это полностью непоследовательно ... :) ... как плохой пример ...

• возьмите Ruby ... там все полностью динамический ... объект имеет его переменные, видимые только из внутри, и класс, определяющий его методы ... вы можете изменить этот класс во время выполнения или даже вы можете назначить другой класс для этого самого объекта ... напуганный ... а также рубиновый операторы - это методы объектов ... у тебя невероятный язык конструкции как блоки ...

• возьмите ECMA-Script (например, JavaScript) ... здесь все является объектом ... функции объекты первого класса ... объект имеет набор свойств (полностью динамический), некоторые из которых могут быть функции, выступающие в роли объекта методы ... вы можете использовать метод одного объекта и применить его к вместо этого другой (не обязательно имеет смысл, но возможно) ... может использоваться любая функция, чтобы создать экземпляр нового объекта ... и так на ... ECMA-Script не имеет концепция уровней доступа, но вы можете скрыть данные с помощью замыканий, если необходимо ... ECMA-Script не работает знаю классы ... но наследование достигается через его прототип на основе природа ...

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

я думаю, вам следует взять JavaScript или Ruby (хотя я думаю, что JavaScript лучше, а затем перейти к ActionScript 2, чтобы иметь его типизированную версию и классы, интерфейсы и т. д.)... или начните с ActionScript 2 напрямую), чтобы показать концепции ООП, поскольку они очень радикальны, ясны и просты ... или, может быть, другие языки сценариев ...

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

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

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

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

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

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

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

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

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

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

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

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

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

            greetz

            back2dos

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

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

            greetz

            back2dos

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

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

            greetz

            back2dos

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

Например, возьмем классический пример «автомобиля». Теперь у вас есть программа для водителя "road", в которой есть функция "carCrash (Car car1, Car car2)". Объясните, как объекты взаимодействуют друг с другом.

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

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

Например, возьмем классический пример с «автомобилем». Теперь у вас есть программа для водителя "road", в которой есть функция "carCrash (Car car1, Car car2)". Объясните, как объекты взаимодействуют друг с другом.

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

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

Например, возьмем классический пример с «автомобилем». Теперь у вас есть программа для водителя "road", в которой есть функция "carCrash (Car car1, Car car2)". Объясните, как объекты взаимодействуют друг с другом.

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

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