Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

What is the difference between module vs. 开发者_JAVA技巧component design?

---

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)

---

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.

---

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).

---

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

---

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!

---

Component is a runtime entity (can be made up of modules), independent runnable unit

Module is a partitioned system into implementation units, independent task assignment. Modules might or might not be a component

---

In my view, Module and Component are all just a couple of functions and assets.

And the different between them is:

Component has business logical and module not.

For example,this text input area is just a Module, but when there was some post api called,it become a Component. you can put a module everywhere and it will work fine, but Componet just can be used in a specific page or view(coz it has a specific api call)