Створюючи додаток з нуля, я повинен починати з об'єктно-орієнтованої (OO) моделі чи моделі відносин між сутністю (ER)?
Створюючи додаток з нуля, я повинен починати з об'єктно-орієнтованої (OO) моделі чи моделі відносин між сутністю (ER)?
Відповіді:
Ви можете спробувати дотримуватись принципу затримки архітектурних рішень якомога довше. Думається, що ви в майбутньому дізнаєтесь більше про свою проблемну область, ніж зараз, - тому будь-які рішення, які ви приймаєте сьогодні, підозрілі.
Ще одним хорошим принципом, щоб поєднати це, може бути спершу спробувати спробувати найризичніші частини своїх вимог - думка полягає в тому, що якщо ти будеш робити легкі частини, то виявиш, що ризиковані частини рухають тебе в іншому напрямку, у тебе немає повторно робити легкі деталі. Тут ризиковано означає речі, які ви не впевнені, як слід їх робити.
З огляду на ці два, і зважаючи на те, що я часто намагаюся наблизитись до речей з точки зору ООС, ви можете спершу спробувати почати з моделі ОО найризикованіших частин вашої програми та застосувати як мінімум можливий обсяг коду, який може задовольнити ризиковані вимоги. Потім почніть розширювати модель OO за необхідності, щоб додати необхідну функціональність. Весь цей час ви можете повністю затримати рішення щодо того, використовувати SQL чи NoSQL, плоскі файли чи хмарне сховище чи будь-що інше ... і, врешті, ви можете виявити, що взагалі не хочете реляційних (ухиляючи від необхідності модель ER).
Модель ER диктує, як зберігатимуться дані програми, а модель OO вирішує, як ці самі дані будуть зберігатися в пам'яті або під час роботи програми. Отже, схема схеми баз даних (модель ER) та конструкція структури класів (модель OO) пов'язані між собою дизайнерськими міркуваннями, і зазвичай їх можна думати одночасно. Насправді, якщо ви використовуєте інструмент об'єктно-реляційного відображення (ORM) , ваша модель ER та модель OO можуть бути одними і тими ж. Іншими словами, ваші класи (модель OO) можуть бути анотовані таким чином, що вони самі визначають модель ER.
Перш ніж проектувати, переконайтеся, що ви дуже добре уявляєте фактичні вимоги програмного забезпечення, для чого воно буде використовуватися, як воно буде використовуватися та хто ним буде користуватися. Багато розробників починають замислюватися над дизайнерськими рішеннями ще до того, як повністю зрозуміють потреби, які повинен вирішувати виріб, і закінчують дизайн, який не підходить для справжньої мети програми.