Is there a difference between a component and a module

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.

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.

Abstract software granularity hierarchy

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.

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.

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.

Filed under: softwareengineering - @ 13:58

Thẻ: architecture, design

Thiết kế website giá rẻ

Danh mục