Дизайн модуля и компонентов

Ответ 1

Я хотел бы поделиться своей идеей об этой разнице.

Оба компонента и модуль используются для обозначения группы функций или части функции. Модуль более логичен, например: модуль Finance, модуль HR, модуль Manufacturing... в системе ERP. С другой стороны, компонент более физический. В программном обеспечении это может быть dll, ocx, exe,...

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

Ответ 2

В OSGi есть ссылка, в которой я полагал, что объяснение различий очень хорошее.

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

Ответ 3

Если вы имеете в виду модуль в смысле модульности, существует определение в стандартном терминологии IEEE по терминологии программного обеспечения:

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

И Dr. Бертран Майер заявил о пяти критериях модульности:

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

Ответ 4

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

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

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

Я видел, что компонентный дизайн используется для принудительного применения некоторых понятий жестких модульность. Этот подход нельзя рекомендовать из-за значительные накладные расходы на композицию: сложность композиции возрастает многочлен с числом компонент. И количество компоненты линейно растут с количеством функциональных групп, потому что, как только вы начнете с модульности по компоненту разложение, вы заставляете себя создавать новый компонент всякий раз вам в противном случае просто нужен новый модуль, потому что этот новый модуль в противном случае на самом деле не было бы нигде. На 100 компонентах составные накладные расходы стали полной занятостью, и каждая композиция итерация заняла бы пару недель, несмотря на многочисленные усилия по автоматизации. Это значительно затрудняло развитие.

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

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

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

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

Ответ 5

Для цифровой разработки и рассмотрения пользовательского интерфейса (HTML/CSS/JS) я использую этот подход для обеспечения того, чтобы я оставался организованным и думал, прежде чем делать. Доказано, что он создает более чистый, более организованный код, который прекрасно переносит работу с меньшими затратами.

В обычной таблице стилей я сейчас настраиваюсь следующим образом:

/* Style Guide – Mobile First
   1. =Setup
   2. =Modules as independent units made up of components
   3. =Components as group of reusable code containing more than one element
   4. =Classes
   5. =Responsive as enhancement
*/

• Модули как самостоятельные блоки, состоящие из компонентов: Верхний колонтитул, Нижний колонтитул, Разделы, Статьи, Рядом и т.д. Дом состоит из многих комнат, со специальными стилями и функциями для создания независимого целого.
• Компоненты как группа многоразового кода, содержащего более одного элемента: Unordered Lists, Quotes, Cards, Tables и т.д.

Я написал более полное объяснение, которое вы можете прочитать здесь.

Надеюсь, это поможет!

Ответ 6

Компонент - это среда выполнения (может состоять из модулей), независимый runnable unit

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