В чем разница между дизайном модулей и компонентов?
Спасибо
В чем разница между дизайном модулей и компонентов?
Спасибо
Я хотел бы поделиться своей идеей об этой разнице.
Оба компонента и модуль используются для обозначения группы функций или части функции. Модуль более логичен, например: модуль Finance, модуль HR, модуль Manufacturing... в системе ERP. С другой стороны, компонент более физический. В программном обеспечении это может быть dll, ocx, exe,...
Нет критериев для измерения того, какой из них больше другого. Один компонент может содержать список модулей, а один модуль также может содержать много компонентов. Компоненты используются для моделирования системы в техническом представлении, а модуль используется для моделирования системы в представлении функций (функциональные возможности системы)
В OSGi есть ссылка, в которой я полагал, что объяснение различий очень хорошее.
Модули против компонентов Разве это не похоже на то, что модули и компоненты имеют много общего? Они оба обеспечивают вещи друг другу и потреблять вещи друг от друга. Они также упакованы как самостоятельные единицы развертывания. Разве эти два не могли считаться одним и тем же или, по крайней мере, быть объединены? Да, они могли, но компоненты и модули обслуживают разные цели и несколько ортогональны (они не полностью ортогональны, потому что компоненты сделаны из кода, который в конечном итоге может быть упакован в модули). Модули имеют дело с упаковкой кода и зависимостями между кодом. Компоненты иметь дело с внедрением функций более высокого уровня и зависимостей среди компонентов. Компонентам требуется управление зависимостями кода, но они технически не нужна модульная система для этого (часто его программисты делают это через путь класса). Хорошее изложение состоит в том, что вы можете думать о модулях как о статическом коде и зависимости от времени компиляции, тогда как компоненты имеют дело с экземплярами и временем выполнения зависимостей.
Если вы имеете в виду модуль в смысле модульности, существует определение в стандартном терминологии IEEE по терминологии программного обеспечения:
"Модульность - это степень, в которой система или компьютерная программа состоит из дискретных компонентов, так что изменение одного компонента оказывает минимальное влияние на другие компоненты".
И Dr. Бертран Майер заявил о пяти критериях модульности:
Компоненты и модули слишком часто смешиваются друг с другом. Oни однако, не одно и то же, а последствия одного - не обязательно для другого.
Модульность - это разбиение кода на модули связанных функциональность. Во многих языках программирования модуль - это просто исходный файл. Общепринято, что если исходный файл тоже растет большой, вы можете разбить его на два или более исходных файла и поместить их в новый каталог; в то время как каталог часто не называется модулем, этот вид разложения по-прежнему является модульным.
Компонент, с другой стороны, может быть составлен по-разному с помощью другие компоненты для формирования разных программ. То есть, есть отдельный этап композиции, где реальные люди решают, какие компоненты должны использоваться вместе.
Я видел, что компонентный дизайн используется для принудительного применения некоторых понятий жестких модульность. Этот подход нельзя рекомендовать из-за значительные накладные расходы на композицию: сложность композиции возрастает многочлен с числом компонент. И количество компоненты линейно растут с количеством функциональных групп, потому что, как только вы начнете с модульности по компоненту разложение, вы заставляете себя создавать новый компонент всякий раз вам в противном случае просто нужен новый модуль, потому что этот новый модуль в противном случае на самом деле не было бы нигде. На 100 компонентах составные накладные расходы стали полной занятостью, и каждая композиция итерация заняла бы пару недель, несмотря на многочисленные усилия по автоматизации. Это значительно затрудняло развитие.
Моя самая простая рекомендация - держаться подальше от компонентов, если вообще возможное; зная, что компоненты иногда могут быть необходимостью. Например, если несколько независимых организаций участвуют в проекта, один компонент для каждой организации представляется приемлемым.
Это вопрос вкуса, как мелкозернистый разложение в модули должны быть, хотя все согласны с тем, что модульность является хорошей вещь.
Если я знаю имя функции, мой редактор найдет ее достаточно скоро. С другой стороны, если по какой-то причине я не знаю названия функция (или класс в этом отношении), модульность становится больше важный.
Я бы ожидал, что в последнем случае будет только проблема для функциональности, которая вы можете воспользоваться этой программой, поэтому постарайтесь сделать декомпозиция вашей программы в модули отражают интуитивно понятную декомпозиция поведения вашей программы в области функциональность.
Для цифровой разработки и рассмотрения пользовательского интерфейса (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
*/
Я написал более полное объяснение, которое вы можете прочитать здесь.
Надеюсь, это поможет!
Компонент - это среда выполнения (может состоять из модулей), независимый runnable unit
Модуль - это секционированная система в единицы реализации, независимое назначение задачи. Модули могут быть или не быть компонентом