# Module pattern

In software engineering, the module pattern is a design pattern used to implement the concept of software modules, defined by modular programming, in a programming language with incomplete direct support for the concept.
This pattern can be implemented in several ways depending on the host programming language, such as the singleton design pattern, object-oriented static members in a class and procedural global functions. In Python, the pattern is built into the language, and each .py file is automatically a module. The same applies to Ada, where the package can be considered a module (similar to a static class).

## Definition & Structure

The module software design pattern provides the features and syntactic structure defined by the modular programming paradigm to programming languages that have incomplete support for the concept.

## Concept

In software development, source code can be organized into components that accomplish a particular function or contain everything necessary to accomplish a particular task. Modular programming is one of those approaches.
The concept of a "module" is not fully supported in many common programming languages.

## Features

In order to consider that a Singleton or any group of related code implements this pattern, the following features must be supplied:
* A portion of the code must have global or public access and be designed for use as global/public code. Additional private or protected code can be executed by the main public code.
* A module must have an initializer function that is equivalent to, or complementary to an object constructor method. This feature is not supported by regular namespaces.
* A module must have a finalizer function that is equivalent to, or complementary to an object destructor method. This feature is not supported by regular namespaces.
* Supporting members may require initialization/finalization code that is executed by the module's initializer/finalizer function.
* Most members are functions that perform operations on elements external to the class, provided as arguments by calling functions. Such functions are "utilities", "tools" or "libraries".

## Implementations

The semantics and syntax of each programming language may affect the implementation of this pattern.

### Object-oriented programming languages
#### Java

Although Java supports the notion of a namespace, a reduced version of a module, some scenarios benefit from employing the design pattern instead of using namespaces.
The following example uses the singleton pattern.

##### Implementation
#### C# (C Sharp .NET)

C#, like Java, supports namespaces although the pattern remains useful in specific cases.
The following example uses the singleton pattern.

##### Implementation
### Prototype-based programming languages
#### JavaScript

JavaScript is commonly used to automate web pages.

##### Implementation
### Procedural programming languages

This pattern may be seen as a procedural extension to object-oriented languages.
Although the procedural and modular programming paradigms are often used together, there are cases where a procedural programming language may not fully support modules, hence requiring a design pattern implementation.

#### PHP (procedural)

This example applies to procedural PHP before namespaces (introduced in version 5.3.0). It is recommended that each member of a module is given a prefix related to the filename or module name in order to avoid identifier collisions.

##### Implementation
#### C

Note that this example applies to procedural C without namespaces. It is recommended that each member of a module is given a prefix related to the filename or module name in order to avoid identifier collisions.

##### Implementation
#### Procedural Pascal

Note that this example applies to procedural non-modular Pascal. Many Pascal dialects have namespace support, called "unit (s)". Some dialects also support initialization and finalization.
If namespaces are not supported, it is recommended to give all member names a prefix related to the filename or module name in order to prevent identifier collisions.

##### Implementation
## Comparisons to other concepts
### Namespaces

Both namespaces and modules allow to group several related entities by a single identifier, and in some situations, used interchangeably. Those entities can be globally accessed. The main purpose of both concepts is the same.
In some scenarios a namespace requires that the global elements that compose it are initialized and finalized by a function or method call.
In many programming languages, namespaces are not directly intended to support an initialization process nor a finalization process, and are therefore not equivalent to modules. That limitation can be worked around in two ways. In namespaces that support global functions, a function for initialization and a function for finalization are coded directly, and called directly in the main program code.

### Classes and namespaces

Classes are used sometimes used as or with namespaces. In programming languages that don't support namespaces (e.g., JavaScript) but do support classes and objects, classes are often used to substitute for namespaces. These classes are usually not instantiated and consist exclusively of static members.

### Singleton classes and namespaces

In object-oriented programming languages where namespaces are incompletely supported, the singleton pattern may be used instead of static members within a non-instantiable class.

### Relationship with other design patterns

The module pattern can be implemented using a specialization of the singleton pattern. However, other design patterns may be applied and combined, in the same class.
This pattern can be used as a decorator, a flyweight, or an adapter.

## Module as a design pattern

The Module pattern can be considered a creational pattern and a structural pattern. It manages the creation and organization of other elements, and groups them as the structural pattern does.
An object that applies this pattern can provide the equivalent of a namespace, providing the initialization and finalization process of a static class or a class with static members with cleaner, more concise syntax and semantics.
It supports specific cases where a class or object can be considered structured, procedural data. And, vice versa, migrate structured, procedural data, and considered as object-oriented.