Есть ли разница между компонентом и модулем

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

В чем разница с компонентами? Я посмотрел это в некоторых книгах, но описание компонентов очень похоже.

Условия похожи. Я обычно думаю, что «модуль» больше, чем «компонент». Компонент представляет собой отдельную деталь, обычно относительно небольшого объема, возможно, общего назначения. Примеры включают элементы управления пользовательского интерфейса и «фоновые компоненты», такие как таймеры, помощники потоков и т. Д. «Модуль» - это большая часть целого, обычно нечто, выполняющее сложную основную функцию без внешнего вмешательства. Это может быть библиотека классов приложения, которая обеспечивает интеграцию с электронной почтой или базой данных. Он может быть таким же большим, как одно приложение из пакета, например, «Модуль дебиторской задолженности» ERP / бухгалтерской платформы.

Я также считаю «модули» более взаимозаменяемыми. Компоненты могут быть реплицированы, причем новые выглядят как старые, но в некотором роде «лучше», но обычно дизайн системы более строго зависит от компонента (или замены, разработанной в соответствии с очень специфическим поведением этого компонента). В некомпьютерных терминах «компонент» может быть блоком двигателя автомобиля; Вы можете повозиться в двигателе, даже полностью заменить его, но автомобиль должен иметь двигатель, и он должен соответствовать очень жестким спецификациям, таким как размеры, вес, точки крепления и т. д., чтобы заменить «стандартный» двигатель, которым автомобиль был изначально разработан, чтобы иметь. «Модуль», с другой стороны, подразумевает функциональность типа «плагин»; каким бы ни был этот модуль, с ним можно общаться таким легким способом, что модуль может быть удален и / или заменен с минимальным воздействием на другие части системы. Электрическая система дома очень модульная; Вы можете подключить что-нибудь с вилкой 120V15A к любой розетке 120V15A и ожидать, что то, что вы подключаете, будет работать. Домашняя проводка может не заботиться о том, что и где подключено, при условии, что энергопотребление в любой отдельной ветви системы не превышает безопасных пределов.

Общее значение модуля - это группа многократно используемого кода, не привязанная к одной конкретной программе. Это может быть что угодно, от целого набора библиотек GUI до одного класса.

Общее значение компонента - это модуль с дополнительным ограничением заменяемости с использованием определенного интерфейса. Если вы создаете компонент виджета GUI, его можно использовать везде, где ожидается виджет, без необходимости делать что-то особенное в вызывающем коде. Модули вообще не имеют такого ограничения. Qt и GTK + являются модулями, но я не могу поменять один на другой без значительной работы в вызывающем его коде, поэтому они не являются компонентами.

Многие фреймворки или языки программирования используют термины для обозначения чего-то гораздо более конкретного, поэтому люди спрашивают о контексте. Что-то может быть компонентом в общем смысле, но если оно не реализует очень специфический IComponentинтерфейс, оно не может рассматриваться как компонент в контексте. В python moduleимеет очень специфический технический смысл того, что вы можете получить с помощью importкоманды. Обычно люди обращаются к этим контекстно-специфическим значениям.

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

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...

• Продукт

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

• модуль

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

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

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

• Составная часть

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

Как следует из названия, в отличие от модуля, компонент не является «автономным», он является частью большего функционального целого.

• объект

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

• Примитивный

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

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

• Какой смысл всего этого?

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

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

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

• Терминология предостережения

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

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

Это зависит от вашего контекста. Модуль уже используется для ссылки на группы уровня DLL в некоторых языках, сродни «пакету» или «сборке» в других. Компонент используется для вещей COM, а также для компонентов Entity Based Component, общих для разработки игр.

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

Компоненты, с другой стороны, имеют тенденцию быть меньшими связками кода, часто меньшими, чем полный класс. По своему названию они имеют тенденцию быть компонентом чего-то большего. Иногда это само приложение, но с ростом использования композиции в дизайне классов оно чаще означает компонент более крупного объекта. Четко определенные интерфейсы для компонентов также позволяют приложению менять компоненты друг для друга. Модули, как правило, не имеют такой возможности обмена.