Как можно преподавать ОО, не ссылаясь на физические объекты реального мира? [закрыто]

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

Первоначальная концепция ОО не имеет ничего общего с тем, чем является сегодня ОО. (См. Так что * действительно * Алан Кей имел в виду под термином "объектно-ориентированный"? ). Сегодняшнее объектно-ориентированное программирование - это создание объектов, таких как метафоры велосипедов, домов, людей и т. Д. Я настоятельно рекомендую придерживаться их, потому что цель метафор заключается в том, чтобы помочь людям понять с помощью концепции, которую они уже понимают. Помогите им увидеть корреляцию, затем помогите им увидеть различия, КОГДА они погружаются в более глубокие вещи об ОО.

РЕДАКТИРОВАТЬ: Сегодняшняя ОО о создании полностью автономных объектов, чьи свойства и способности полностью / частично описаны с использованием различных методов (функций) и атрибутов (ссылается на переменные и константы АКА).

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

Это также предотвращает «взрыв объекта», чрезмерное обобщение и неправильный выбор метафоры, которые являются общими ошибками.

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

Например, если вы работаете в C, в котором нет встроенного ОО, вам может быть удобно хранить указатели на функции внутри объектов данных. Если вы это сделаете, то вы вклиниваетесь в ООП.

Мне не нравится ссылаться на Алана Кея, как если бы он был Моисеем, раздающим таблетки. Скорее, он был обучен математике и био, я считаю. Как математик, он, вероятно, был знаком с Lambda Calculus, который был довольно абстрактным, не связанным с аппаратным обеспечением. В LC вы можете сказать, что все является «объектом» - например, число 0 и число 1 являются объектами, которые оценивают разные вещи при задании аргумента. Это очень хорошо ведет в Smalltalk. Идея «сообщения» такова, что мы можем избежать разговоров об аппаратном обеспечении. Вы можете сказать, что когда вы вызываете функцию (или метод объекта), вы отправляете ему сообщение, а когда он возвращается, он отправляет вам сообщение (или вашему продолжению). Это было зафиксировано как способ описания способов взаимодействия между программами, работающими асинхронно на отдельном оборудовании. Все в порядке, но для обычного программирования это увлекается. Чтобы понять ценность идеи ООП, вам не нужно отрицать актуальность конкретной задачи, которую вы пытаетесь выполнить, или отрицать конкретность оборудования, на котором вы работаете. Я думаю, что преподавание ООП с помощью надуманных аналогий заставляет людей слишком много задумываться о разработке программного обеспечения с точки зрения структуры данных, что приводит к чрезмерному проектированию, приводит к раздутию кода и огромным проблемам с производительностью, которые мне приходится тратить на очистку, когда это становится достаточно плохо.

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

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

Нет, вы не должны учить этому без физических объектов реального мира

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

Интересно, что некоторые из моих любимых примеров не являются физическими объектами. Взять, к примеру, банковский счет. Каждый «понимает», почему deposit () иdraw () должны взимать плату за обслуживание, а не полагаться на код вызова для изменения значения баланса и не забывать снимать плату за обслуживание. Фигуры на экране вдвойне нематериальны, и Страуструп сказал мне, что классический пример «Фигуры» - это один из двух самых старых примеров ОО, которые он знает, он датируется 40 лет назад (другой - транспортные средства, сейчас 44 года).

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

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

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

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

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