Module vs. component design

Question

What is the difference between module vs. component design?

Solution 1

I'd like to share my idea about this difference.

Both component and module are used to refer to a group of functions or a part of a function. Module is more logical, for example: module Finance, module HR, module Manufacturing... in ERP system. On the other hand, component is more physical. In software, it can be a dll, ocx, exe,...

There is no criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many components. Components are used to model a system in technical view, and module is used to model the system in function view ( functionalities of the system)

Solution 2

Components and modules are too often confused with each other. They are, however, not the same, and the implications of one, does not necessarily hold for the other.

Modularity is the partitioning of code into modules of related functionality. In many programming languages, a module is simply a source file. It is common practice that if the source file grows too big, you can split it into two or more source files, and put these into a new directory; while a directory is often not called a module, this kind of decomposition is still modular.

A component, on the other hand, can be composed in different ways with other components to form different programs. That is, there is a separate composition stage, where real people decide which components should be used together.

I have seen component design being used to enforce some notion of hard modularity. This approach cannot be recommended because of the rather significant overhead of composition: the composition complexity grows polynomial with the number of components. And the number of components grows linearly with the number of functionality groups, because once you get started with modularity by component decomposition, you force yourself to create a new component whenever you would otherwise just need a new module, because that new module would otherwise not really belong anywhere. At a 100 components, the composition overhead became a full-time job, and each composition iteration would take up to a couple of weeks, despite numerous automation efforts. This significantly impeded development.

My simplest recommendation is to stay away from components if at all possible; well-knowing that components may sometimes be a necessity. For instance if multiple independent organizations are involved in a project, one component for each organization seem acceptable.

It is a matter of taste, how fine grained your decomposition into modules should be, though everyone agrees that modularity is a good thing.

If I know the name of a function, my editor will find it soon enough. On the other hand, if for some reason I don't know the name of a function (or a class for that matter), modularity becomes more important.

I would expect the later case, to only be an issue for functionality that you can experience from using the program, so try to make the decomposition of your program into modules reflect an intuitive decomposition of the behaviour of your program into areas of functionality.

Solution 3

There is a reference in the «OSGi in Action» book, which, I believe, explains the differences well.

Modules vs. components

Doesn't it sound like modules and components have a lot in common? They both provide stuff to each other and consume stuff from each other. They're also packaged as independent deployment units. Couldn't these two be considered one and the same or at least be combined? Yes, they could, but components and modules serve different purposes and are somewhat orthogonal (they're not completely orthogonal, because components are made from code that can ultimately be packaged into modules).

Modules deal with code packaging and the dependencies among code. Components deal with implementing higher-level functionality and the dependencies among components. Components need their code dependencies managed, but they technically don't need a module system to do it (often it's us programmers doing it via the class path).

A good summary is that you can think of modules as dealing with static code and compile-time dependencies, whereas components deal with instances and execution-time dependencies.

— «11.1.1 What are components?», «OSGi in Action» (page 347).

Solution 4

If you mean module in the sense of modularity there is a definition in the IEEE Standard Glossary of Software Engineering Terminology:

"Modularity is the degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components."

And Dr. Bertrand Meyer stated five criteria for modularity:

• Decomposability of the problem into sub-problems
• Composability of modules to produce new systems
• Understandability of a module in isolation
• Continuity - small changes have localized effects
• Protection - fault isolation

Solution 5

For digital development and UI consideration (HTML/CSS/JS), I use this approach to ensure I'm staying organized and thinking before doing. Has proven to create cleaner, more organized code which translates nicely to doing more with less.

In a typical stylesheet, I'm currently setting up like this:

/* 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
*/

• Modules as independent units made up of components: Header, Footer, Sections, Articles, Aside, etc. A house is made up of many rooms, all with special styles and functions to create an independent whole.
• Components as a group of reusable code containing more than one element: Unordered Lists, Quotes, Cards, Tables, etc.

I wrote a fuller explanation you can read here.

Hope this helps!

View more solutions

Comments

[Gerrat]

If you're going to quote an official source, it would be preferable to get the quote right: The degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components

[arpadf]

Agree; I just want to reinforce this view. The key to understanding the difference between modules and components is in how we view the system: a static view where the modules and the dependencies between them are derived directly from the code and an instance view where the components and the dependencies/links between them are result of runtime processing and/or a separate pre-execution configuration step.

[arpadf]

This is definitely a wrong answer. Quoting from support.microsoft.com/en-us/kb/815065: "The use of DLLs helps promote modularization of code, code reuse, [...]" - you cannot say "component is more physical", DLLs are all about modularity and you cannot get more physical than that.

[arpadf]

Same for OSGI bundles osgi.org/developer/architecture: "Therefore, modularity is at the core of the OSGi specifications and embodied in the bundleconcept. In Java terms, a bundle is a plain old JAR file" - again modules are physical.

[ESR]

I like the assertion that a component contains business logic and a module doesn't

[Klent Abistado]

I agree to @Tin, the use of the term "physical" may be debatable but in general Tin's answer is much clearer.

[Klent Abistado]

I agree with you @arpadf

[Klent Abistado]

Me too @ESR, that's a point.