Сама доповідь Джеймса Коплієна

А від класів ніхто не відмовився, вони є у trygve: 5. Class-Oriented Programming. Немаэ поліморфізму через успадкування.
Але ж знову — клас це більш низкорівнева абстракція відносно контекстів та ролей.

Так, за допомогою класів та інтерфейсів можна виразити DCI, можна ввести конвенції, так як у прикладах на C#. Але все одно на ріні компілятора не буде усіх необхідних перевірок, як з процедурами. Але це теж варіант, якщо наприклад переходити на trygve немає сенсу за відсутності під нього необхідних фреймворків та ліб.

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

Але є і мова trygve, яка включає абстракції DCI на рівні синтаксиса та семантики...

Що використовувати, та чи використовувати взагалі — це вибір архітектіа, або lead девелопера (якщо на проекті немає архітекта)...

Високорівневі абстакції, які маюь певну семантику, відсутню у процерури.
Наприклад тут зрозуміло що э певна роль SourceAccount яка маэ метод transfert_monery, також вона вимагаэ від data объекта наявість метода decrease_balance і таке інше. Тобто ця мова виражає деяку суть.

role SourceAccount
{
   void transfert_monery(DestinationAccount destination)
   {
     ...
   }
   require
   {
     decrease_balance(decimal);
   }
}

Але структура з адресами процедур, не маэ такої виразності — йде втрата інформації.

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

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

Але якщо є мова у яку вбудовані всі ці абстакції, то це ІМНО гуд. Код стає більш структурованим, та зрозумілим, компілярор на етапі компіляції може виявити більше помилок та таке інше.

Так, на Assembler теж все це можна зобити...
А чому ні, ствоюємо на стеці необхідні данні(або адреса даних у випадку якихось строк), ось тобі — D, потім туди ща пушаєм адреси процедур, ось тобі — I. А потім робимо кол контекстної процедупри, ось тобі — С! Евріка, теж DCI! ))

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

Ok, я про це впринципі і кажу. Але спочатку мені здалося що ви протиставляєте ці практики ооп по вашим тезам.

Ні в якому разі не протиставляю. На більшості сучасних мов, можна емулювати DCI за допомогою власноруч створених абстракцій, як показано у прикладах. Але building blocks DCI не вбудовані на рівні мов, і не форсять девелопера їх використовувати, окрім спеціально створеної мови trygve.

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

Тому я бачу DCI наступним чином:
Є объекти з данними, у них немаэ поведінки. І це деколи добре, тому що, якщо об’єкт може бути актором у багатьох контекстах, і для кожного такого контекста він має у собі самому поведінку — то це перевантажуэ відповідальність об’єкта, порушується принцип Single Responsibility. І як результат ми маємо величехні класи, які потім складніше розуміти, та сапортити. Я з таким песпосередньо зустрічався на декількох проектах. Ти дійсно не розумієш чому система веде себе так. А тому що, десь там у якомусь предку, є віртуальна функція яка не перегружена у іншому предку (хоча у більшості однорівневих йому предках вона перегружена) і т.і.

А ось коли э окремий контекст для конкретного UseCase, і поведінка об’єкта прописана у цьому контексті — це на мою думку добре. Код добре структурується таким чином. QA каже, ось у цьому UseCase баг. Ти відкриваєш UseCase, дивишся які там об’єкти фігурують, яка у них поведінка, і зразу все стає зрозумілим. Тому що весь код у одному місті, код не перетинається з іншими поведінками, немає ніякого поліморіфзму, тому немає там десь у глибині якоїсь несподіванки.

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

У ООП теж ключовим є поняття об‘єкту, а не классу. Дивись js, до появи класів там було ооп реалізоване на об‘єктах прототипах.

Ну так JS це одна із небагатьох мов яка по справжньому підтримує ООП (а не КОП — клас орієнтовне програмування). Ти міг(і доречі можеш зараз) зробити:

Object obj = new Object();
obj.my_method = functiion()
{
  // Do work
}

А ось тут, ти займаэшься розробкою класу, а не песпосередньо об’єкта, тому вони вважають це більш class-орієнтед, ніж object-орієнтед.

class MyClass
{
  public my_method()
  {
    // Do Work
  }
}

Якщо відкинути теоретичну складову і говорити мовую практиків — Не зрозуміло, що є building block програми у вашій новій парадигмі

Ну як не зрозуміло. Все зрозуміло.
Я сприймаю DCI — як високорівневеву надстройку над справжнім ООП програмуванням (без використання поліморфізму). Ось її building blocks:

— Data — це data складова об’’эктів
— Interaction — поведінкова, залежно від контекста
— Context — це якійсь Use Case

Якщо ви дивились приклад на trygve, то ви бачили як в run-time до data складової об’єтка додається поведінкова у контексті MoneyTransfer. От Вам і справжнє ООП.

До речі ця парадигма не є такою ж і новою. Вона створена на прикінці 90-x — як більш прозора, та зрозуміла альтернатива КОП. Її автор дуже не задоволений КОП, і більш за все поліморфізмом. DCI почала популяризуватись десь на початку 2000-х. Але у той момент гіганти бізнесу продвигали клас орієнтовні мови, наприклад C++ та Java. В популяризацію Java наприклад, було вбухано багато грошей і на цьому фоні багато цікавих речей стали непомітними.

але у прикладах вище це звичайний ооп під різним соусом.

Ще раз Вам кажу, придевитесь. Java, C#, ... — це клас орієнтовні мови. Ви будуєте класи.
В JS, та trygve наприклад, ви беспосередньо констуюєте об’єкти в рантаймі. Тобто додаєте до об’єктів(ще раз підкреслюю, не класів) нові методи, та свойства.

Дякую за feedback.

Наступний свій web pet-проект планую робити на DCI. Тому думаю, напишу ще щось на цю тему.
Слідкуйте за анонсами на DOU.

Доброго дня.

Парадигма — це спосіб класифікації підходів у програмуванні.

Наприклад у процедурному програмуванні данні відокремленні від поведінки, а поведінка реалізована у процедурах. У клас орієнтовному програмуванні(то що ми називаємо ООП) — навпаки, данні об’єднані з методами у класи. Є ще декілька парадигм, наприклад Prototype-орієнтоване програмування, та т.і.

Відносно, DCI — як я писав у статті, головними структурами є об’экти (не класи), які:
— мають data складову, яка описуэться класами, чи структурами, чи спеціальними конструкціями (зележно від мови програмування)
— є учасниками якихость UseCases, котрі реалізовани у вигляди Contextів
— а їх поведінка, чи взаъмодія (Interaction) описана ролями у конкретних конекстах.

Тобто є UseCase, перевод коштів з одного акаунта на другий. Йому відповідає Context — TransferMoney. Акторами у цьому контексті э два акаунта (Data складов). І на ці акаунти, у момент створення контескту, накладаються дві ролі: на перший акаунт роль SourceAccountRole, на другий: DestinationAccountRole. Це э у прикладі.

Також у DCI немаэ поліморфізму (через успадкування) — що спрощує спрйняття коду.

Перечитайте статтю, в ній все сказано. Якщо, все ще не розумієте — скіпайте, значить це не для Вас.

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

Ну і як на мене DCI парадигма більш проста для розуміння, та імплементації, та гнучка ніж highweight DDD.

Я наприклад зараз бачу, що DCI більш підходить для використання у Business Applications домені, ніж у системному.

Ця парадигма має одну, дуже важливу з моє точки зору фічу. Вона дає можливість виражати дуже чітко Use Cases. Ні ООП, ні процедурна парадигма такого не дають.

На найвищому рівні абстракції у процедурній парадигмі знаходиться процедура, чи модуль з процедурами. У ООП це клас(хоча на справді об’єкт). Але це все деталі реалізації. У цих парадигмах відсутній уровень документації, опису Use Cases, акторів системи, їх поведінки. Є класи, сервіси, API, та інші девелоперські речі.

Але ж ви розумієте, що ми продаємо не класи, ні АПІ, ні патерни кінцевому юзеру? Ми продаємо функціонал, який описаний Use Caseами.

Тому основний плюс DCI, це наява уровня абстракції, котрий описує Use Cases! Ви відкриваєте код і зразу бачите всі Use Cases з усіма ролями, та імплементацією поведінки кожної ролі.

Зазвичай на ООП проекті є діаграми, та текстові файли з Use Cases, та окремо код який це реалізує. І це проблема. Треба постійно сінхронізувати доку з кодом, ти не бачиш явно в коді де реалізован той чи інший UseCase.

Також, як я писав у статті, відсутність поліморфізму, спрощує розуміння коду. Але з моєї точки зору поліморфізм має право на життя у інфраструктурному коді, у фреймворках, де перевантачуючи деякі методи, ми змінюємо дефолтну поведінку системи.

Круто, якщо воно надійно працює не тільки на простих задчах. Тому що, я відчув різницю при переході з ATMega на STM32, коли щоб помігати LED, треба сконфігурувати багато речей у випадку STM32.

Тобто наприклад можливо писати під ATMega, а потім просто переключитись на STM32 і все взлетить без зайвих дій?

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

З іншого боку, є така формула: make it work, make it good, make it fast.
Якщо Ви володієте Arduino, та зможете створити працюючий контролер с деякими обмежаннями по таймінгам, то це вже IMHO на 90% перемога. Потім перенести на інше залізо буде відносно не складно.

Доброго дня.

А чому ви вибрали Arduino?
Ви якось обчислювали, чи достатньо його обчислювальних можливостей?

Гнідота бля.

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

Так, для Путіна це вихід.

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

Ти хоч читав мій пост чи ні?

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