Чи об'єктно-орієнтоване програмування реально моделює реальний світ? [зачинено]

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

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

Хоча деякі об'єкти, які я створюю, моделюють реальні об'єкти, чи не попередній OOP-код зробить те саме? Я сумніваюся, що OO були першими, хто включив такі поняття, як «Замовник» у свої кодові бази. Але OO насправді полягає в тому, як моделювати речі, і цей метод моделювання мені не здається натхненним реальним світом.

Отже: чи об'єктно-орієнтоване програмування насправді моделює реальний світ?

Ні, зовсім ні.

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

Моделі будь-якого типу не моделюють реальний світ, не повністю.

Вони моделюють вибрані частини, ті, які стосуються програми.

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

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

Є чи об'єктно - орієнтоване програмування дозволяє моделювати реальний світ?

Однозначно ТАК

Практично неможливо моделювати систему, щоб вона точно відповідала реальному світу.

Мені завжди доводиться моделювати програмне забезпечення саме за реальним світом?

НЕМАЄ

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

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

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

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

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

... Світ багатший за те, що можна виразити об'єктно-орієнтованим синтаксисом.

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

Процеси надзвичайно поширені в реальному світі та програмуванні. Протягом багатьох років були розроблені розроблені механізми для управління транзакціями, робочим процесом, оркестрованістю, потоками, протоколами та іншими суттєво «процедурними» концепціями. Ці механізми породжують складність, намагаючись компенсувати притаманний дефіцит інваріантності часу програмуванню ОО. Натомість проблему слід вирішувати в корені, дозволяючи конкретним процесам конструкцій, таких як "до / після", "причина / наслідок" і, можливо, "системний стан" бути основною частиною мови ...

Джерело цитати: Вікторія Лівшіц, Наступний крок у програмуванні

Так, ОО часто можна використовувати для моделювання реальних сутностей.

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

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

Для інкапсуляції сутності ми можемо моделювати цю сутність за її реальною світовою колегою. Наприклад, якщо у нас є гітара, то клас гітари інкапсулює поведінку та властивості реальної гітари світу. Ми можемо додатково абстрагувати гітару як, скажімо, користь IInventoryItemдля використання потенціалу повторного використання коду через поліморфізм та успадкування.

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

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

Це залежить від того, про який реальний світ ви говорите.

Хорхе Луїс Борхес написав оповідання "Tlön, Uqbar, Orbis Tertius", де один з жителів народів, схоже, сприймає свій реальний світ зовсім по-іншому:

[...] люди уявного Тльона [...] дотримуються крайньої форми беркельського ідеалізму, заперечуючи реальність світу. Їх світ розуміють "не як збіг предметів у просторі, а як різнорідний ряд незалежних актів". В одній із уявних мов Тльона бракує іменників. Його центральними одиницями є "безособові дієслова, кваліфіковані за односкладовими суфіксами або префіксами, що мають силу прислівників". Борхес перераховує тлонічний еквівалент "Місяць піднявся над водою": hlör u fang axaxaxas mlö, що означає буквально "Вгору позаду потоку, який він причаїв". [...] В іншій мові Tlön "основна одиниця - не дієслово, а односкладовий прикметник", який у поєднанні двох і більше є іменниковим: "місяць" стає "круглим повітряним світлом на темний "або"

(скопійовано із статті вікіпедії про книгу)

Для мене справа не стільки в тому, що світ можна сприймати інакше, ніж у нас, що є своєрідним кліше, але саме сприйняття структури реальності залежить від мови, якою ми розмовляємо, будь то природна чи мова програмування. Tlönese може бути дуже задоволений від Lisp і може бачити Яву (AKA The Kingdom Of Nouns ) дуже неприродною, тоді як більшість програмістів-терранів, як правило, віддають перевагу об'єктно-орієнтованим функціональним мовам. Мені подобаються обидва стилі, оскільки я думаю, що це головним чином питання перспективи. Деякі проблеми найкраще атакувати з функціональними, інші - з об'єктно-орієнтованими методами програмування. Хороший програміст завжди дивиться на складну проблему з різних точок зору, перш ніж спробувати вирішити. Або, як сказав Алан Кей: Точка зору коштує 80 балів IQ .

Отже, моя відповідь на ваше запитання: про який реальний світ ви говорите? І як?

Хоча деякі створені мною об'єкти моделюють об'єкти реального світу, чи не попередній OOP-код не зробив би те саме?

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

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

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

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

Він не моделює наш світ, але моделює людську інтерпретацію нашого світу. Люди природно відокремлюють речі як предмети. ОО є ефективним, оскільки дозволяє людині програмувати так, як вони думають.

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

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

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

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

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

Мені здається, це не стосується нічого, що є поза бізнес-шаром.

Ні. Як ви зазначаєте, багато речей, "модельованих" мовою OOP, є абстрактними поняттями, такими як черги повідомлень, контролери та стеки.

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

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

Тому моделі не повинні намагатися (або робити вигляд) повністю представляти "Реальний світ".

Хоча деякі створені мною об'єкти моделюють об'єкти реального світу, чи не попередній OOP-код не зробив би те саме? Я сумніваюся, що OO були першими, хто включив такі поняття, як «Замовник» у свої кодові бази.

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

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

Найбільша різниця між OOP і non-OOP полягає в тому, що OOP прив'язує код до даних. Отже, а не називати такий код:

verb(noun);

ми робимо це замість цього:

noun->verb();

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

Чи об'єктно-орієнтоване програмування реально моделює реальний світ?

Не повністю.

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

Наприклад, якщо проблема з кошиком була проблемою, у нас є різні суб'єкти

1. Продукт, який є абстрактним терміном, який може мати декілька членів, як-от Книги, Гаджети, Автомобілі, які знову можна розділити.

2. Податкові критерії на кшталт (податок з продажу) залежатимуть від того, в якому місці програмне забезпечення буде впроваджене, оскільки воно підлягає змінам на основі урядової політики.

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

4. Користувач може мати кошик для покупок, у якому є список товарів тощо.

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

Я думаю, ви занадто багато читаєте те, що має бути дуже прозаїчним, історичним, твердженням. Багато ідей програмування OO, класів, поліморпізму, віртуальних функцій тощо були введені мовою Simula ще в 60-х роках (http://en.wikipedia.org/wiki/Simula). Як випливає з назви, Simula був розроблений як мова для написання симуляцій. Так історично так, так, ідеї ОО були запроваджені, намагаючись моделювати "реальний світ". Чи вдасться їм досягти успіху більше, ніж інші стилі - це питання дискусії.

Хоча деякі створені мною об'єкти моделюють об'єкти реального світу, чи не попередній OOP-код не зробив би те саме?

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

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

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

Але OO насправді полягає в тому, як моделювати речі, і цей метод моделювання мені не здається натхненним реальним світом.

Я вважаю, що це має більше стосунку до того, як ми сприймаємо світ, ніж того, яким він є насправді. Можна стверджувати, що все - це лише купа атомів (або енергії, або хвиль, як би там не було), але це не допомагає нам впоратися із завданням вирішення проблем, з якими ми стикаємось, з розумінням оточення навколо нас та прогнозуванням майбутніх подій ( або опису минулих). Таким чином, ми робимо "ментальні моделі" світу, і часто ці ментальні моделі знаходять кращу відповідність з ОО, ніж дані + процеси, які, мабуть, моделюють "краще", як реально працює світ.

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

Однак є також "прототипний OOP", де об'єкт описується шляхом вибору подібного та перерахування аспектів, де вони відрізняються. Я б запропонував цей нарис для хорошого і не надто технічного пояснення процесу мислення (весь пост занадто великий, навіть для стандартів Стіва Йегге, тому я вказую на відповідний розділ: P). Знову ж таки, це гарна відповідність для наших ментальних моделей, коли ми уявляємо невідомі екземпляри порівняно з відомими, але не обов'язково для того, як "працює" реальний світ ... (дві корови насправді повністю розбивають сутності, навіть якщо ми їх сприймаємо як багато в чому подібних)

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

Стаття Вікіпедії з цього питання підсумовує це добре:

Моделювання та взаємозв'язки
в реальному світі OOP можна використовувати для асоціації об'єктів і процесів реального світу з цифровими аналогами. Однак не всі згодні з тим, що ООП сприяє прямому картографуванню в реальному світі (див. Розділ «Негативна критика») або що картографування в реальному світі є навіть гідною метою; Бертран Мейєр стверджує в «Об’єктно-орієнтованій програмі побудови програмного забезпечення» [21], що програма - це не модель світу, а модель деякої частини світу; "Реальність - двоюрідна сестра, яку двічі знімали".

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

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

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

Для того, щоб подумати про орієнтацію на об'єкт у відповідному контексті, давайте перейдемо на один рівень абстракції і поговоримо про програмування взагалі, гаразд?

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

Окрім розгляду того, яку поведінку має впроваджувати програма, ваша програма, як правило, повинна проявляти певні якості. Наприклад, недостатньо, щоб програма для моніторингу серця вимагала поведінки, необхідної для цього - зазвичай вона також повинна виконуватись досить швидко, щоб працювати майже в реальному часі. Інші "якості", які програма може проявити, це: безпека, гнучкість, модульність, розширюваність, читабельність тощо. Ми називаємо ці атрибути якості архітектури . Тому ми можемо сказати, що нашій програмі необхідно відповідати певним поведінковим (функціональним) цілям, а також виявляти певні якості (нефункціональні).

Поки нічого з цього не говорили про ОО, чи не так? Давайте зробимо це зараз.

Як тільки інженер розуміє вимоги (поведінкові, AQA, обмеження тощо), виникає питання: як я впорядковую свій код, щоб він робив усі необхідні для цього завдання, виявляючи також якості, необхідні для корисної програми? Об'єктно-орієнтоване програмування - це стратегія організації функціональності вашої програми в згуртовані модулі взаємодіючих об'єктів. Функціональне програмування - це ще одна стратегія організації функціональності вашої програми, і вона робить це по-іншому. Обидві стратегії мають свої сильні та слабкі сторони.

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

Але повернувшись до ОО, зараз ви можете бачити, що це не обов'язково моделювати "реальний світ"; що це - організувати поведінку вашої програми, щоб ваша програма могла проявляти якості, необхідні для досягнення будь-якої кількості бізнес-цілей. Такі методи, як TDD, DDD та BDD - це способи, яким ми розкриваємо, як найкраще організувати наші об'єкти. У таких книгах, як " Принципи", "Шаблони" та "Практики" , Зростаюче об'єктно-орієнтоване програмне забезпечення, кероване тестами , Специфікація на прикладі та Дизайн, керований доменом, викладаються теорія та практика орієнтації на об'єкти з акцентом на дизайн, орієнтований на поведінку.

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

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

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

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

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Іншим прикладом є автоматизовані рамки тестування прийому користувача на основі мови Gherkin .

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

Це залежить від вас, нарешті. Але OOP - це точніший спосіб, ніж інші методики, такі як Структуроване або Процедурно-орієнтоване програмування. Процедурний такт може, можливо, вирішити ваші проблеми, але дотримання OOP може полегшити вам життя.