I have a little problem with the terms module and component. In my mind, a module are bundled classes, which are only accesable via a well defined interface. They hide all implementation details and are reusable. Modules define modules on which they depend.

What is the difference to components? I looked it up in some books, but the description of components is very similar.

  • 4
    Which language? Which architecture? Your definition of module works. I think of a component as something that plugs into something for say a GUI while a module can not plug into a GUI; modules can work in a GUI if wrapped/supported by GUI constructs. – Guy Coder Dec 10 '12 at 16:32
  • 3
    See Class vs. Component vs. Control Note: I am not answering because your question does not mention langauge or architecture. – Guy Coder Dec 10 '12 at 16:35
  • Yes, in this case, I think about the definitions in general – Mirco Dec 10 '12 at 16:47
  • 2
    I am not after points, more after making sure you get a valid answer. If you find this valid, then feel free to edit your question and add the link as the answer you prefer. I will not post it as an answer because the question is too general and a specific answer can get others into trouble. – Guy Coder Dec 10 '12 at 16:51
  • Yeah, I think my question is very general and the answer really depends on the used language or enviornement. Nerver thought there are so much different definitions for these terms – Mirco Dec 10 '12 at 16:54

The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope, possibly general-purpose. Examples include UI controls and "background components" such as timers, threading assistants etc. A "module" is a larger piece of the whole, usually something that performs a complex primary function without outside interference. It could be the class library of an application that provides integration with e-mail or the database. It may be as large as a single application of a suite, such as the "Accounts Receivable module" of an ERP/accounting platform.

I also think of "modules" as being more interchangeable. Components can be replicated, with new ones looking like old ones but being "better" in some way, but typically the design of the system is more strictly dependent upon a component (or a replacement designed to conform to that component's very specific behavior). In non-computer terms, a "component" may be the engine block of a car; you can tinker within the engine, even replace it entirely, but the car must have an engine, and it must conform to very rigid specifications such as dimensions, weight, mounting points, etc in order to replace the "stock" engine which the car was originally designed to have. A "module", on the other hand, implies "plug-in"-type functionality; whatever that module is, it can be communicated with in such a lightweight way that the module can be removed and/or replaced with minimal effect on other parts of the system. The electrical system of a house is highly modular; you can plug anything with a 120V15A plug into any 120V15A receptacle and expect the thing you're plugging in to work. The house wiring couldn't care less what's plugged in where, provided the power demands in any single branch of the system don't exceed safe limits.

  • 4
    All answers really helped me, but I can only accept one. So I accept KeithS's because he has the lowest rep – Mirco Dec 10 '12 at 17:07

The generic meaning of module is a group of reusable code, not tied to one specific program. This could be everything from an entire set of GUI libraries down to a single class.

The generic meaning of component is a module with the additional restriction of substitutability using a specific interface. If you create a GUI Widget component, it can be used anywhere a Widget is expected, without having to do anything special in the calling code. Modules in general have no such restriction. Qt and GTK+ are modules, but I can't swap out one for the other without considerable work in the code calling it, therefore they are not components.

Many frameworks or programming languages use the terms to mean something much more specific, which is why people are asking about context. Something may be a component in the generic sense, but if it doesn't implement a very specific IComponent interface, it may not be considered a component in context. In python, module has the very specific technical meaning of something you can get using an import command. Usually people are referring to these context-specific meanings.

  • Your definition is fine, but your example (Qt vs. GTK+) is flawed (though I agree that I would not call any of them a component, too). IMHO Qt and GTK+ both contain hundreds of small components, thus resulting in a very broad collection of interfaces. That makes it very unlikely that someone will ever invest the time to create an interface compatible replacement for one of them, and that is IMHO the reason why they are no components. However, just because two pieces of software cannot be interchanged does not disqualify them as components, only as components with a common interface. – Doc Brown Dec 10 '12 at 17:53

If we are to abstract from particular languages, frameworks and their own interpretations, the abstract software granularity hierarchy is the following:

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

Plain and simple, the Product is a working collection of connected functional modules.

  • Module

As the very name implies, the motivation of a Module is modularity. Contrary to what many claim, it does not really imply code reuse. There are many modules which are not really reusable, and don't fit with anything they were not designed to.

It is important to separate different software layers, that makes software much easier to implement and maintain, and should the need to reimplement something like a front end to a different GUI framework, modularity enables that to happen in an easy and safe manner, without breaking code all over the place.

A module encapsulates a collection of components which all serve a common purpose as defined by the module requirements. A module should be self-contained and complete, and while not really usable on its own, it should be able to work in conjunction with any conforming implementation.

  • Component

In terms of granularity the Component sits between the Module and the Object. The purpose of a component is to put together a collection of general purpose objects to form a purpose specific unit.

As the name implies, unlike the Module, the Component is not "self-contained", it is a part of a larger functional whole.

  • Object

Objects are the smaller building blocks of components. Objects are collections of primitives and couple them together to serve a lower level, more universal while still somewhat specific purpose.

  • Primitive

Primitives are the smallest, simplest and lowest level of software development granularity. It's basically just integer and real numbers and functions/operators, although most languages have their own additional "first class citizens".

There is very little you can do with primitives, and at the same time, it is at a such a low level that you can accomplish practically everything with it. It is just very, very verbose, insanely complicated and impossibly tedious to accomplish while directly working with primitives.

  • What's the point of all this?

As already mentioned above, working with primitives directly is an extremely bad idea. Not only because it is impossibly complex, slow and tedious to do for modern day software development, but it is also extremely obtrusive and obstructive to testing and maintenance.

Having all of those conceptual parts incorporated into software development makes it easier, faster, simpler and safer. You don't make a house out of atoms, regardless of how versatile and universal atoms are. That would be an exercise in futility. Your atoms are your primitives, clay is your object, bricks are your components, walls, floor and roof are your modules, assembled together they manifest the final product.

Humans don't really invent anything, we only discover things already out there in the universe, and then copy and apply them to our lives. The same granularity hierarchy is intrinsic to the universe itself, from atoms and even below, to organic molecules, proteins, tissues, organs, organisms and above, reality itself obeys the same principle - combining small, simple, function limited and purpose abstract things into larger, more complex, more functional things and more purpose specific things.

  • Terminology caveats

Technically they are all "objects", they are all "components" of software development, they are all "modular" enough to be able to fit together, they are all "products" in the sense that they have been produced and so on...

This is not about terminology or nomenclature, it is about how scaling things up and out affects various aspects of creativity and productivity. And about the importance of not only using all those different levels, but also the importance of not trying to accomplish a goal at the wrong level, which can only be counterproductive.

  • Your version of module sounds like a package. – J. M. Becker May 2 at 17:22
  • @J.M.Becker not really, in terms of granularity a package can consist of anything from a collection of objects to a full standalone product. Packaging is more of a convenience thing for code reuse than a link in the granularity chain. – dtech May 28 at 9:12

It depends on your context. Module is already used to refer to DLL level groups in some languages, akin to 'package' or 'assembly' in others. Component is used for COM things as well as Entity Based Component stuff common in game development.

In general architectural terms, module and component do both tend to refer to some bundle of code behind a well defined interface. In general, module tends to refer to larger bundles. There's often a set of interfaces and the module tends to be able to stand on its own.

Components on the other hand tend to be smaller bundles of code, often smaller than a full class. By their name, they tend to be a component of something larger. Sometimes that is the application itself, but with the increasing usage of composition in class design it more often means a component of a larger object. The well defined interfaces for components also tends to allow the app to swap components in for each other. Modules tend not to have that swapability.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.