Що означає "ООП приховує державу"? [зачинено]

В одній із багатьох анти-ООП-рейтів на cat-v.org я знайшов уривок Джо Армстронга, який висунув кілька заперечень проти моделі ООП, одним з яких було таке:

Заперечення 4 - Об'єкти мають приватний стан

Держава - корінь усього зла. Зокрема, слід уникати функцій з побічними ефектами.

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

Зважаючи на те, що держава існує в реальному світі, які засоби програмування повинні передбачати мову програмування для роботи з державою?

OOPL кажуть "приховати стан від програміста". Стани приховані і видимі лише через функції доступу. Звичайні мови програмування (C, Паскаль) кажуть, що видимість змінних стану контролюється правилами області застосування мови. Чисті декларативні мови говорять про те, що немає держави. Глобальний стан системи здійснюється у всіх функціях і виходить з усіх функцій. Такі механізми, як монади (для FPL) та DCG (логічні мови) використовуються для приховування стану програміста, щоб вони могли програмувати «як би стан не мав значення», але мати повний доступ до стану системи, якщо це буде необхідно.

Опція «приховати стан від програміста», обрана OOPL, є гіршим можливим вибором. Замість того, щоб розкривати державу і намагатися знайти способи мінімізувати неприємності держави, вони приховують це.

Що саме мається на увазі під цим? У мене дуже мало низького рівня чи процедурного досвіду, переважно OOP, так що, ймовірно, пояснюється, наскільки я незнайомий з цим. І з більш сучасної точки зору, тепер, коли більшість об'єктно-орієнтованих істерій пройшли (принаймні, наскільки я можу сказати), наскільки точним / релевантним ви вважаєте, що це уривок?

Спасибі за вашу допомогу.

Що саме мається на увазі під цим?

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

як точний / релевантний ви думаєте, хлопці, цей пасаж?

Я відчуваю, що це актуально, але неправильно. Існує абсолютно проблема, якщо ваш клас просочує поняття свого стану до зовнішнього світу. Абсолютно виникає проблема, якщо ваш клас намагається затьмарити державу, коли вона повинна маніпулювати зовнішнім світом. Це хоч і не є збоєм ООП в цілому, але з індивідуальним дизайном класу. Я б не сказав, що приховування самої держави є проблемою - монади роблять це у функціональному програмуванні постійно.

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

Чи ООП ускладнює людям досягнення найкращих справ? Можливо. "Школи Java" і вся форма "Кола / Прямокутник" або "Автомобіль" має колеса для викладання шкіл колеса OO, ймовірно, більше винні, ніж сам підхід. Сучасний OOP займає досить багато функціонального програмування, заохочуючи незмінні об'єкти та чисті функції, при цьому відлякуючи спадщину, щоб полегшити проектування класів, які добре працюють.

Обґрунтувати систему буде важко, якщо є шматки змінного стану, які не мають єдиного чіткого "власника". Це не означає, що об’єкти ніколи не повинні мати змінний стан, а навпаки, що об'єкти, які мають змінний стан, не повинні використовуватися способами, коли право власності може бути незрозумілим, і навпаки, об'єкти, які потрібно буде вільно передавати навколо, не відстежуючи право власності бути незмінним.

На практиці ефективне програмування часто вимагає, щоб деякі об'єкти мали змінений стан; такий стан, однак, повинно бути обмежено, однак, нерозділені об'єктів робочих. Розглянемо IEnumerable/ IEnumeratorінтерфейси в .NET: якщо колекція реалізується IEnumerable, вона дозволить прочитати елементи по черзі. Фактичний процес зчитування колекції часто вимагає відстеження, які елементи були прочитані (фрагмент змінного стану), але такий стан не міститься в рамках реалізації IEnumerable. Натомість IEnumerableнадає метод, GetEnumeratorякий називається, який поверне об'єкт, який реалізує IEnumeratorта містить достатній стан, щоб дозволити зчитування елементів із колекції. Те, що об'єкт містить такий стан, не створюватиме проблем, протеякщо реалізація об'єкта IEnumeratorне поділяється .

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

Загрожуючи вийти за рамки відповіді на питання, легко помітити недоліки в ідеї ООП, але я схильний думати, що сила ідеї відображається в її здатності до зловживань.

Зрештою, у кожного є своя улюблена мова, яку вони описують такими термінами, як "дуже дуже потужна", тобто вони їм дуже подобаються . Але дивовижність обчислювальної універсальності полягає в тому, що якою б славною не була мова, якщо вона справді потужна, вона може імітувати асемблерну мову. І якщо може, хтось побачить, що це робить. (Не те, що в мові складання нічого поганого.)

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

Я особисто хотів би побачити наступний рівень, де люди навчаться вирішувати проблеми, дивлячись на них мовно. Де вони зрозуміли б поняття домен-конкретних мов, як їх легко зробити та дозволити їх створенню невід'ємною частиною вирішення проблем. Неправильно сказати, що структура даних - це мова. Люди повинні мати таку навичку мовного дизайну, тому вони не просто блукають через це.

Тоді, як на наступному рівні, я хотів би, щоб штучний інтелект зміцнювався. Мені хотілося б, щоб програмісти рухалися за байтами та потоками, а також віртуальними таблицями функцій та CUDA та переходили до того, як змусити машини міркувати, вчитися та створювати. Я знаю, що це просунулося дуже далеко в невеликих куточках поля, але ніде досить широко.

Доступність не є особливістю OOP, вона специфічна для таких реалізацій, як Java та Microsoft dotNET. Основна особливість, яка визначає ООП, - поліморфізм.

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

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