Difference between a module, library and a framework
In popular programming speak, what is the difference between these terms and what are the overlaps?
Any related terms I'm missing out?
Solution 1:
All three of those provide functionality.
However, there are important differences.
A library is just a collection of related functionality. Nothing more, but also nothing less. The defining characteristic of a library is that you are in control, you call the library.
The defining characteristic of a framework is Inversion of Control. The framework calls you, not the other way round. (This is known as the Hollywood Principle: "Don't call us, we'll call you.") The framework is in control. The flow of control and the flow of data is managed by the framework.
You can think of it this way: in both cases, you have an application, and this application has holes in it, where code has been left out, and these holes need to be filled in. The difference between a library and a framework is
- who writes the application,
- what are the holes and
- who fills in the holes.
With a library, you write the application, and you leave out the boring details, which gets filled in by a library.
With a framework, the framework writer writes the application, and leaves out the interesting details, which you fill in.
This can be a little confusing at times, because the framework itself might also contain boring details, that the framework author filled in with libraries, the parts that you write might contain boring details, that you fill in with libraries, and the framework might provide a set of bundled libraries that either work well with the framework or that are often needed in conjunction with the framework. For example, you might use an XML generator library when writing a web application using a web framework, and that XML library might have been provided by the framework or even be an integral part of it.
That doesn't mean, however, that there is no distinction between a library and a framework. The distinction is very clear: Inversion of Control is what it's all about.
The defining characteristic of a module is information hiding. A module has an interface, which explicitly, but abstractly specifies both the functionality it provides as well as the functionality it depends on. (Often called the exported and imported functionality.) This interface has an implementation (or multiple implementations, actually), which, from the user of a module are a black box.
Also, a library is a collection of related functionality, whereas a module only provides a single piece of functionality. Which means that, if you have a system with both modules and libraries, a library will typically contain multiple modules. For example, you might have a collections library which contains a List module, a Set module and a Map module.
While you can certainly write modules without a module system, ideally you want your modules to be separately compilable (for languages and execution environments where that notion even makes sense), separately deployable, and you want module composition to be safe (i.e. composing modules should either work or trigger an error before runtime, but never lead to an runtime error or unexpected behavior). For this, you need a module system, like Racket's units, Standard ML's modules and functors or Newspeak's top-level classes.
So, let's recap:
- library: collection of related functionality
- framework: Inversion of Control
- module: abstract interface with explicit exports and imports, implementation and interface are separate, there may be multiple implementations and the implementation is hidden
Solution 2:
You can see a module, a library and a framework this way:
- module = your fingers
- library = your hands
- framework = your body
Your fingers / Module:
You can move them, touch things, you have 5 in a hand so you can use them to hold things in an easier way, those are not the biggest parts of the body but are one of the most useful parts, without them you couldnt hack!... modules are part of a program, you can use them, expand code to other files (not a large file with a lot of code in it), they make the reading easier.
Your hands / Library:
Hands are a set of 5 fingers each one, you can hold things, move things, interact with them, etc... libraries are part of a program too! and they can be seen like a set of modules, you can use them to interact with other programs or make relevant things with your program.
Your body / Framework:
Your body is a complete system, you can do with your body whatever you want (even fly, just walk into a plane and there you go, a plane is another system), you are unique... a framework is your body, a complete system, it doesnt work for itself (you need to code herpderp) but you can make a complete program with some hacking runs...
just my interpretation... if im wrong please fix ME.
Solution 3:
My ASCII art interpretation of what I understood from other answers:
+-----------------------------------------------+
| ........................... .............. |
| : f1() f2() : f3() : : f4() f5() : |
| : : : : : |
| : l1_module1 : l1_module2 : : l2_module3 : |
| : : : : : |
| --library1----------------- --library2---- |
| |
| application.c |
| |
| #include l1_module2 |
| #include l2_module3 |
| |
| int main() { |
| # case 'reload' |
| f5(); |
| # case 'start' |
| f1(); |
| # case 'stop' |
| f4(); |
| } |
| |
+-----------------------------------------------+
.................................................
: FRAMEWORK_X :
: :
: application start :
: ... :
: application reload :
: application stop :
: ... :
:...............................................:
What happens:
Developer installs library1 and library2 so that they can use functions provided inside modules of these.
They then include l1_module1 and l2_module3. (They do not need l1_module2 for now).
Now they can use the functionality of f1, f2, f4 and f5, So they write their application.
Now, since they want to use the application inside some FRAMEWORK_X, they must implement the interface that this framework needs: so that the framework can call the application.
Some notes:
- In practice, there is always some framework. For example, the OS
is framework for your application (which is why you define
main())! Or you could say that the bootloader is framework for your OS and the BIOS is framework for your bootloader etc.
Solution 4:
Package vs Module vs Library vs Framework:
-
Package - Collection of classes/files of similar functionality.
-
Module -It is the smallest piece of software. It is set of methods/functions ready to be used somewhere else.
-
Library - It is a collections of packages. It offer a set of functionalities ready to use without worrying about the how it has been written. All we bother about is input/output.
-
Framework - It's a set of libraries. along with functionalities, it also provides an architecture design or wire frame. It offers well designed patterns to your project. we don't include a framework. we integrate our code into it.
Solution 5:
Roughly, I'd consider it this way: a module is an importable "atom" of functionality; it defines the smallest subset of grouped functionality that can be used (note that it's not the smallest unit of functionality; that would be a class (or function, depending)). A library would be, in this approach, a set of modules; you can use a library without using all of the modules that are part of that library. A framework is the environment upon which the library (likely) depends; it makes up the baseline environment within which all of the above work.
Note that these terms are somewhat fungible, and these definitions will not always be solid in every situation; this is just my interpretation of some of the common usages I've come across.