На тему моделювання предметної області в термінах ООП

Привіт.

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

Кожен раз при моделюванні предметної області, оперуючи термінами ООП (зараз говоримо не про етапі бізнес-аналізу, а про подальшому етапі реалізації моделі в коді), для всіх сутностей предметної області доводиться реалізовувати в коді і схемою БД наступний паттерн, який складається їх «подсущностей», пов'язаних між собою:
  • клас/таблицю «Машини» (тут і далі клас вживаю в термінах ООП);
  • клас/таблицю виду «Список машин»;
  • клас/таблицю виду «Машина».
Далі з допомогою механізмів ООП та реляційної моделі «подсущности зв'язуються між собою.

Причому терміни „сутність“ і „подсущность“ застосовні саме до моделі предметної області в термінах теорії множин,
а в термінах ООП/реляційної моделі доречні терміни „метасущность“ і „сутність“ відповідно.
Сподіваюся, зрозуміло, чому? — ООП/реляційна модель є більш низькорівневими механізмами, і сутність предметної області доводиться конструювати, немає в них коштів, які нативними чином дозволили б відобразити сутність предметної області.

А далі йдуть очікувані проблеми:


Кожний раз (не тільки в кожному проекті, а всередині проекту для кожної сутності, підкреслю це) реалізуємо патерн?
Відмінно, ми займаємося копіпастом.

[offtopic]Відволікаючись, хотілося б сказати, я досить критично ставлюся до паттернам (тема така модна 10-15 років вже як; адже чого тільки не придумують замість того, щоб займатися моделюванням і написанням якісного коду),
т. к. паттертн — це копіпаст по своїй суті (якщо комусь захочеться посперечатися на тему — будь ласка не тут, заведіть публікацію, там поговоримо).[/offtopic]

Або, якщо хочеться скоротити собі роботу/не займатися копіпастом (або у разі відсутності розуміння необхідності реалізації описаного патерну), в більшості випадків робиться так, реалізується лише одна сутність:
  1. Код:
    • клас „Машина“ — не безліч, а саме характеристики машини, її опис;
    • список машин представляється аби як — масив (Array), список (List), або перерахування (IEnumerable), тобто використовуються низькорівневі типи даних мови для реалізації сутності „список“ — але з такими даними ми можемо робити, що хочемо або що випадково вийде, а це вже не об'єктний, а процедурний підхід з усіма витікаючими;

    • клас ж „машини“ найчастіше взагалі не реалізується ні в якому вигляді.
  2. БД:
    • Як правило, це одна таблиця „Машина“ або „Машини“ — таблиця, рядки яких містять список машин, а стовпці — характеристики машин.
    • Ніколи не замислювалися, чому в книжках з БД таку таблицю називають, „Машина“, „Машини“ (Student/Students)?
      Є фреймворки по роботі з БД, які примусово до назв таблиць додають суфікс „s“ (Mashines/Students).
    • Причина в тому, що тут відбувається спроба об'єднати дві сутності в одну (об'єкт і список об'єктів), або навіть всі три в одну.
    • Правильно називати таку таблицю „Машина“, а „Список машини“ і „Машини“ реалізовувати за допомогою інших таблиць.
Так ось який висновок я роблю на підставі свого досвіду і коментованій статті:
Хотілося б мати такі мова програмування, платформу розробки, теорію БД, СУБД, які дозволили б в „рідних“ для себе термінах реалізовувати модель предметної області в термінах саме теорії множин.
Мені здається, необхідність появи таких інструментів в мейнстрімі давно вже назріла.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.