Наскільки архітектура програмного забезпечення залежить від мови?

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

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

Що робити, якщо мова, якою написана система, взагалі не має таких понять? Наприклад, якщо я використовую Python або Node, які динамічно набираються і не мають поняття інтерфейсу? Що робити, якщо я використовую TypeScript, коли інтерфейс є ефемерною конструкцією, якої не існує під час виконання? Що робити, якщо я намагаюся використовувати функціональне програмування? Чи слід ігнорувати, наприклад, SOLID і шукати інші поняття, відповідні моїй мові?

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

Як взагалі ви б описали залежність між архітектурою та мовою?

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

Є багато матеріалів, які можна використовувати для побудови будинку. Можна використовувати цеглу або ліпнину. Можна використовувати дерев’яні балки або металеві. Кожен матеріал має свої особливості, що стосуються ваги, міцності тощо. Всі ці характеристики впливають на архітектуру.

Таким же чином, мова програмування, яку ви використовуєте, впливає на спосіб побудови вашої архітектури. Ваша архітектура буде виглядати інакше в мові програмування, у якої є класи на зразок C ++, ніж у мові програмування, яка не є, як C.

Принципи SOLID здебільшого стосуються об'єктно-орієнтованих мов (тобто мов, які мають класи).

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

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

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

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

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

Мати сенс?

Я б сказав, для початку, що навіть мова, про яку ви думаєте, має глибокий вплив на те, що ви можете уявити. Є причина, що PASCAL був створений Ніклаусом Віртом, а Брайаном Керніган і Деннісом Річі.

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

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