Як можна навчити ОО, не посилаючись на фізичні об'єкти реального світу? [зачинено]

Я пам’ятаю, що десь читав, що оригінальні концепції, що стоять за ОО, полягали в пошуку кращої архітектури для обробки обміну даними між декількома системами таким чином, щоб захистити стан цих даних. Зараз це, мабуть, погана перефраза, але це змусило мене замислитися, чи існує спосіб викладання OO без аналогій об'єкта (Велосипед, Автомобіль, Особа тощо), і натомість зосереджується на аспектах обміну повідомленнями. Якщо у вас є статті, посилання, книги тощо, це було б корисно.

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

EDIT: Сьогоднішній OO - це створення повністю автономних об'єктів, властивості та здібності яких повністю / частково описані за допомогою різних методів (функцій) та атрибутів (посилання на змінні та константи AKA).

Можна говорити про поняття сполучення та згуртованості. Об'єкти повинні складатися з атрибутів і методів з високою згуртованістю і неявно високою зв'язкою. Вони повинні відображати найменш деталізовані операції та атрибути, необхідні для роботи системи. Вони також повинні задовольняти бажання зберегти код якомога меншим та простішим, тобто кодування з підтримкою та розширенням.

Це також запобігає "вибуху об'єкта", перенасиченості та неправильному вибору метафори, які є загальними помилками.

Я б не зосереджувався на об'єктах реального світу, і я також не зосереджувався на обміну повідомленнями. Швидше за прикладом, який я використав, - це графіка, де ви хочете мати об’єкти, які «вміють малювати самі».

Наприклад, якщо ви працюєте в C, де немає вбудованого ОО, вам може зручно зберігати покажчики на функції всередині об’єктів даних. Якщо ви це зробите, то ви вклинюєте свій шлях до OOP.

Я не люблю посилатися на Алана Кей так, ніби він Мойсей роздавав планшети. Швидше, він навчався з математики та біографії, я вважаю. Як математик, він, мабуть, мав деяке знайомство з обчисленням Лямбди, яке було досить абстрактним, не пов'язаним з обладнанням. У LC можна сказати, що все є "об'єктом" - як число 0, так і число 1 - це об'єкти, які оцінюють різні речі при наданні аргументу. Це призводить до Smalltalk досить красиво. Ідея "повідомлення" така, що ми можемо уникати розмов про обладнання. Ви можете сказати, коли ви викликаєте функцію (або метод об'єкта), ви надсилаєте їй повідомлення, а коли він повертається, він надсилає вам повідомлення (або у ваше продовження). Це було застосовано як спосіб опису способів спілкування між програмами, що працюють асинхронно на окремому апаратному забезпеченні. Це чудово, але для звичайного програмування це захоплюється. Щоб отримати значення ідеї OOP, вам не потрібно заперечувати актуальність конкретної задачі, яку ви намагаєтеся виконати, або заперечувати конкретність обладнання, яке ви працюєте. Я думаю, що навчання про OOP з точки зору надуманих аналогій змушує людей занадто сильно замислюватися про розробку програмного забезпечення з точки зору структури даних, що призводить до її надмірного проектування, що призводить до розмивання коду та масових проблем з продуктивністю, що мені доведеться витрачати час на очищення стає досить погано.

Я б стверджував, що в застосуванні фізичного об'єкта для прикладу є мало різниці, а в якості прикладу використовується нефізичний об'єкт. У коді вони обидва мають абсолютно однакові частини. Якщо ми використаємо графічний приклад і навчимо його за допомогою сфери, куба, циліндра, його майже так само, як використання кульки, коробки, жердини.

Отже, щоб навчити це без використання фізичних прикладів, я б запропонував взагалі не використовувати будь-яких прикладів, але я не бачу, чому ви не хочете фізичних прикладів, тому моя позиція щодо цієї теми

Ні, ви не повинні вчити цього без фізичних об'єктів реального світу

Я не бачу, як можна уникнути початку метафори реального світу, але ти не хочеш там залишатися . Якщо ви правильно робите OOP, він швидко стає абстрактним, але на наступному рівні розуміння учень повинен розуміти об'єкти як об'єкти.

Цікаво, що деякі мої улюблені приклади - це не фізичні об’єкти. Візьмемо, наприклад, банківський рахунок. Кожен "отримує", чому депозит () і зняття () повинні стягувати плату за послугу, а не покладатися на код виклику, щоб змінити значення балансу і не забувати зняти плату за послугу. Фігури на екрані подвійні нематеріальні, і Струструп сказав мені, що класичний приклад "Фігури" є одним із двох найстаріших прикладів ОО, які він знає, починаючи з 40 років (інший - транспортні засоби, яким зараз 44 роки.)

Важливо, щоб люди зрозуміли ваші приклади відразу. Ліфти є хорошим прикладом лише для людей, які всі знайомі з ліфтами. І т.д.

Якщо ви перебуваєте в групі програмування, зберіть кілька людей разом і починайте обговорювати, як ви б сказали один одному робити те, що вам потрібно зробити для системи. Буквально виконайте ролі в системі (ви можете зробити це самостійно, просто зігравши кожну роль, але легше з групою людей. Іграшки допомагають, якщо ви самі). Зосередьтеся на тому, що робить / робити кожна людина, а не на тому, які дані вони мають. Здійснення цього з людьми допомагає зосередити увагу на повідомленнях та ролях, оскільки люди, як правило, пам’ятають, що вони роблять, але не дані, які вони мають.

Візьміть до уваги, що вам потрібно попросити один одного зробити і яку інформацію вам потрібно зробити. Будьте захищені від власних даних, якщо інший програміст попросить ваші дані щось сказати "ні", і запитайте його, навіщо йому це потрібно (допомагає в капсуляції даних).

Я думаю, що підхід «знизу / вгору» може бути корисним. Спочатку поясніть структури та покажчики стилю С, щоб показати, як можна структурувати дані, а не просто використовувати примітиви безпосередньо. Потім поясніть пізні зв'язки та покажчики функцій. Потім поясніть, що ви можете використовувати їх для створення об'єктів, які в основному є добре інкапсульованими купами даних і покажчиками на функції, необхідні для роботи над цими даними.

Це пояснення суперечить звичайному математичному / комп’ютерному способу викладання концепції незалежно від впровадження, але саме така перспектива змусила мене (правда, хтось із інженерії, а не комп, наука) нарешті отримати ОО.