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

Question

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

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

• Уровни доступа
• Наследование
• Инкапсуляция
• Полиморфизм
• Абстракция
• Интерфейсы

Answer 1

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

Использование всех этих популярных метафор просто вводит людей в заблуждение, ИМХО. Автомобили не имеют ничего общего с ООП. Легко понять эти метафоры , когда вы уже знаете, что они означают, но пытаетесь начать с них ... нет.

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

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