Content deleted Content added
m fix code. |
ce, links |
||
Line 1:
In [[software engineering]], the '''module pattern''' is a [[design pattern (computer science)|design pattern]] used to implement the concept of [[software
▲In [[software engineering]], the '''module pattern''' is a [[design pattern (computer science)|design pattern]] used to implement the concept of software modules, defined by [[modular programming]], in a programming language that does not or only partially supports it.
== Definition ==▼
▲There are several ways to implement this pattern, depending on the host programming language, such as the [[singleton pattern|singleton design pattern]], object-oriented static members in a class, and procedural global functions.
The ''module software design pattern'' provides the features and syntactic structure defined by the modular programming paradigm to programming languages that
▲==Definition==
== Structure ==▼
▲The ''module software design pattern'' provides the features and syntactic structure defined by the modular programming paradigm to programming languages that do not support it or support it only partially.
▲==Structure==
[[File:Module-software-design-pattern.png|center|thumb|500px|alt=The object module pattern expressed in [[Unified Modeling Language|UML]].|The object module pattern expressed in [[Unified Modeling Language|UML]].]]
== Concept ==
In software development,
The concept of a "module" is not fully supported
== Features ==
In order to consider that a Singleton or any group of related code implements this pattern, the following features must be
* A portion of the code must have global or public access and be
* A module must have an initializer function
* A module must have a finalizer function
*
* Most members are functions that perform operations on elements external to the class, provided as
▲* Most members are functions that perform operations on elements external to the class, provided as parameters. Those functions are meant to be frequently used as "utilities", "tools" or "libraries".
== Implementations ==
The semantics and syntax of each programming language may
==== Java ====▼
▲===Examples in object-oriented programming languages===
▲====Java====
Although [[Java
The following example uses the singleton pattern.
===== Definition =====
<source lang="java">
Line 130 ⟶ 127:
</source>
===== Implementation =====
<source lang="java">
Line 162 ⟶ 159:
</source>
==== C# (C Sharp .Net) ====
[[C#]], like Java, supports namespaces although the pattern remains useful in specific cases.
The following example uses the singleton pattern.
===== Definition =====
<source lang="csharp">
Line 226 ⟶ 223:
public void printString(String Value) {
}
Line 259 ⟶ 256:
</source>
===== Implementation =====
<source lang="csharp">
Line 293 ⟶ 290:
</source>
===
====
[[JavaScript]] is commonly used to automate web pages.
===== Definition =====
<source lang="javascript">
Line 357 ⟶ 356:
</source>
===== Implementation =====
<source lang="javascript">
Line 386 ⟶ 385:
</source>
===
This pattern may be seen as a procedural extension to object-oriented languages.
Line 392 ⟶ 391:
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]]
===== Definition =====
<source lang="php">
Line 405 ⟶ 404:
// code that prepares a "console"
}
/* void */ console_unprepare() {
// code that unprepares a "console"
Line 446 ⟶ 445:
</source>
===== Implementation =====
<source lang="php">
Line 480 ⟶ 479:
</source>
==== C ====
Note that this example applies to procedural [[C (language)|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.
===== Definition header module =====
<source lang="c">
Line 493 ⟶ 492:
#include <ctype.h>
void consoles_prepare();
void consoles_unprepare();
Line 511 ⟶ 510:
</source>
===== Definition body module =====
<source lang="c">
Line 524 ⟶ 523:
// code that prepares console
}
void consoles_unprepare() {
// code that unprepares console
Line 536 ⟶ 535:
void consoles_printString(char* Value) {
printf("%s", Value);
}
Line 545 ⟶ 544:
void consoles_printBoolean(bool Value) {
if (Value)
{
}
else
{
}
}
Line 569 ⟶ 568:
char temp[512];
scanf("%s", temp);
*Value = (strcmp(Temp, "true") == 0);
}
</source>
===== Implementation =====
<source lang="c">
Line 599 ⟶ 598:
consoles_printNewLine();
consoles_scanNewLine();
}
Line 610 ⟶ 609:
ErrorCode = consoledemo_execute();
consoledemo_unprepare();
return ErrorCode;
}
</source>
==== Procedural Pascal ====
Note that this example applies to procedural non-modular Pascal. Many Pascal dialects
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.
===== Definition =====
<source lang="pascal">
Line 633 ⟶ 632:
(* code that prepares console *)
end;
procedure unprepare();
begin
Line 648 ⟶ 647:
procedure printString(Value: string);
begin
Write(Value);
end;
procedure printInteger(Value: integer);
begin
Write(Value);
end;
Line 659 ⟶ 658:
begin
if (Value) then
begin
end else
begin
end;
end;
Line 686 ⟶ 685:
begin
ReadLn(temp);
if (Temp = 'true') then
begin
Line 697 ⟶ 696:
</source>
===== Implementation =====
<source lang="pascal">
Line 720 ⟶ 719:
consoles.printNewLine();
consoles.scanNewLine();
execute := 0;
end;
Line 731 ⟶ 730:
</source>
== 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 its be the same.▼
▲=== Namespaces ===
There are scenarios where a namespace requires that the global elements that compose it are initialized and finalized by a function or method call.▼
▲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
▲
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.
=== Singleton classes and namespaces ===▼
▲''Classes'' are used sometimes used as or with ''namespaces''. In programming languages that don't support namespaces (e.g. PHP < 5.3.0, 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.
In object-oriented programming languages where namespaces are
▲===Singleton classes and namespaces===
=== Relationship with other design patterns ===▼
▲In object-oriented programming languages where namespaces are not supported or partially supported, the [[singleton pattern]] may be used instead of static members within a non-instantiable class.
The module pattern can be implemented using a specialization of the singleton pattern. However, other design patterns may applied and combined, in the same class
▲===Relationship with other design patterns===
This pattern can be used as a ''[[decorator pattern|decorator]]'', a ''[[flyweight pattern|flyweight]]'', or an ''[[adapter pattern|adapter]]''.▼
▲The module pattern can be implemented using a specialization of the singleton pattern. However, other design patterns may applied and combined, in the same class as well.
== Module as a design pattern ==▼
▲This pattern can be used as a ''decorator'', a ''flyweight'', or an ''adapter''.
The Module pattern can be considered a [[creational pattern]] and a [[structural pattern]]. It
▲==Module as a design pattern==
An object that applies this pattern can
▲The Module pattern can be considered a creational pattern and a structural pattern. It allows to manage the creation of other elements and organize other elements, and group them as the structural pattern does.
▲An object that applies this pattern can perform the functionality 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.
== See also ==▼
▲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.
▲==See also==
* [[Design pattern]]
* ''[[Design Patterns]]'' (E. Gamma et al.)
|