Насколько программная архитектура зависит от языка?

14

Изучая архитектуру программного обеспечения и шаблоны проектирования, я заметил, что в большинстве случаев в объяснении подразумеваются некоторые языковые особенности и особенности проектирования.

Например, практически любая статья или книга, иллюстрирующая идеи с использованием классов и интерфейсов. Все, что можно легко найти в этой теме, будет включать объекты и концепции ООП.

Что если язык, на котором написана система, вообще не имеет таких понятий? Например, что если я использую Python или Node, которые динамически типизированы и не имеют понятия интерфейса? Что если я использую TypeScript, где интерфейс - это эфемерная конструкция, которой нет во время выполнения? Что если я пытаюсь использовать функциональное программирование? Должен ли я игнорировать, например, SOLID и искать другие концепции, подходящие для моего языка?

Если да, то что это? К сожалению, все хорошо принятые парадигмы (насколько мне известно) так или иначе относятся к концепциям и типам ООП. Если нет, каким правилам следует следовать при адаптации общих принципов архитектуры и дизайна к моему конкретному языку и сценарию использования?

Как бы вы описали зависимость между архитектурой и языком?

design-patterns architecture

— Тристан Цара
источник

Я написал статью об архитектуре программного обеспечения: Управление сложностью программного обеспечения linkedin.com/pulse/…

— overexchange

Во-первых, да, программная архитектура основана на технологии, которую вы имеете в виду. Например: python не использует многопоточность, пока эти потоки не будут связаны с IO. Это реальное ограничение в использовании операций с многоядерными процессорами. Во-вторых, вы должны послушать это ... youtu.be/FF-tKLISfPE В-третьих, вы должны проанализировать / поработать над существующими стабильными распределенными корпоративными продуктами определенного домена, который масштабируемо развернут, в течение как минимум 5-6 лет. Это органическое понимание того, как технологии влияют на дизайн. Кстати, такие продукты были написаны в до-Java мире, с нуля.

— сверхобмена

Wrt технологии ... В мире Java, до 6/6/7 дизайн языка Java был под контролем реальных основателей. С java 8 я бы рассматривал java как пропагандистскую машину, но не как язык программирования. На мой взгляд, Java стала технологией менеджера проекта. Поэтому, как новичок, я бы проанализировал / поработал над продуктом, написанным на C / C ++ / Python

— overexchange

Пожалуйста, не используйте слово архитектура в вашем вопросе, это сбивает с толку. Ваш вопрос касается дизайна. Выбор языка, как правило, можно отнести к архитектуре, ваш вопрос не имеет смысла в том виде, в котором он сформулирован ..

— Мартин Маат

Кроме питона и Javascript делать есть интерфейсы, они просто не использовать отдельное ключевое слово , чтобы разграничить их

— Caleth

11

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

Есть много материалов, которые вы можете использовать, чтобы построить дом. Вы можете использовать кирпич или штукатурку. Вы можете использовать деревянные балки или металлические. Каждый материал имеет свои особенности, с точки зрения веса, прочности и так далее. Все эти характеристики влияют на архитектуру.

Точно так же используемый вами язык программирования влияет на то, как вы строите свою архитектуру. Ваша архитектура будет выглядеть по-другому в языке программирования, который имеет классы, подобные C ++, чем в языке программирования, который не имеет, как C.

Принципы SOLID в основном касаются объектно-ориентированных языков (т.е. языков, имеющих классы).

— Роберт Харви
источник

4

Архитектура зависит от возможностей для достижения своих целей. Выбор языка может ограничивать возможности. Любой полный язык Тьюринга имеет возможность выполнить любую задачу программирования. После этого пункта речь идет о том, насколько читабельным является язык, позволяющий найти решение.

Многие схемы архитектуры программного обеспечения просят вас удалить все знания о выборе технологий из основных бизнес-правил домена. Единственный технический выбор, который вы никогда не сможете удалить из ядра, - это язык, на котором вы хотите выразить это.

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

— candied_orange
источник

Хорошие моменты в вашем ответе, но я уверен, что исторически архитектура программного обеспечения была реализована с использованием ТЕХНОЛОГИЙ в тренде.

— сверхобмена

@overexchange - смысл хорошей архитектуры - создавать программное обеспечение, которое сможет пережить текущую тенденцию, будучи готовым к следующей.

— candied_orange

По крайней мере, в мире промежуточного программного обеспечения архитектуры продуктов не могли мыслить дальше RPC / RMI / CORBA до 1990-х годов. Я видел классические дизайны, основанные на процедурно-ориентированных вызовах remore. Затем ServiceOArch изменил тенденцию промежуточного программного обеспечения с точки зрения архитектуры.

— сверхобмена

2

@CandiedOrange это теория. На практике я видел, как многие люди делают то, что иногда называют «разработкой, управляемой шумихой» - просто делайте то, о чем их нынешний круг коллег говорит больше всего во время проектирования, чтобы вы могли принять участие в этом выступлении.

— Марстато

@marstato Согласен. Лучший пример - использование Spring / Springboot в текущей тенденции для любого нового проекта, не зная, почему?

— сверхобмена

1

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

В программном обеспечении архитектурный выбор должен быть сделан таким образом, который соответствует свойствам языка. Если вы строите систему с объектно-ориентированным языком, то я ожидаю, что архитектура системы также будет объектно-ориентированной. Если вы строите систему с функциональным языком, то я ожидаю, что архитектура этой системы также будет функциональной.

Есть смысл?

— RibaldEddie
источник

Спасибо за ваш ответ! Случайно ли вам известны какие-либо ресурсы, посвященные разработке архитектуры программного обеспечения в отношении динамически типизированных или функциональных языков? Все, что я видел, работает, например, для Java прямо из коробки, но потребует некоторой адаптации, например, для js. Каковы возможные рекомендации по адаптации общих архитектурных шаблонов к слабо типизированному языку? Стоит ли даже пытаться это сделать или это что-то совершенно другое?

— Тристан Цара

меня беспокоило то, что если кто-то использует, например, Java, то существует множество лучших практик и шаблонов для архитектуры, но я не видел ни одного для языков другого типа. поэтому мне было интересно, как к ним относиться

— Тристан Цара

в основном, например, SOLID все еще стоит в таком случае? как его адаптировать, если да? что делать, если нет?

— Тристан Цара

Принципы SOLID очень объектно-ориентированы по происхождению. Однако я думаю, что они кодируют принципы высшего порядка, которые могут быть применимы к любой программной системе независимо от языка. Но элементарные принципы именно таковы: вы должны знать и понимать их, прежде чем строить намного больше, чем кормушку для птиц.

— Рибальд Эдди

@TristanTzara Объектно-ориентированное программирование было изобретено до и без какого-либо объектно-ориентированного языка. Вы можете сделать это на любом языке общего назначения. Даже те, которые не имеют классов.

— candied_orange

1

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

На более высоком уровне способность выражать определенные концепции (и отсутствие других) будет направлять вашу мысль и заставлять вас приходить к определенным решениям, которые не обязательно будут такими же, как у другого человека, с другим опытом.

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

— rbanffy
источник