Programming paradigms

Agent-oriented Component-based Flow-based Pipeline Concatenative Concurrent computing Declarative (contrast: Imperative) Functional Dataflow Cell-oriented (spreadsheets) Reactive Goal-oriented Constraint Logic Constraint logic Abductive logic Inductive logic Event-driven Service-oriented Time-driven Feature-oriented Function-level (contrast: Value-level) Imperative (contrast: Declarative) Non-structured Array (contrast: Scalar) Iterative Structured Procedural Modular Recursive Object-oriented Class-based Prototype-based Automata-based By separation of concerns: Aspect-oriented Subject-oriented Role-oriented Metaprogramming Attribute-oriented Automatic Generic Template Policy-based Language-oriented Domain-specific Grammar-oriented Dialecting Intentional Reflective Nondeterministic Parallel computing Process-oriented Programming in the large and programming in the small Value-level (contrast: Function-level)

Modular programming is a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.^[1] Modules are typically incorporated into the program through interfaces. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface.

Languages that formally support the module concept include IBM/360 Assembler, COBOL, RPG and PL/1, Ada, D, F, Fortran, Haskell, BlitzMax, OCaml, Pascal, ML, Modula-2, Erlang, Perl, Python and Ruby. The IBM System i also uses Modules in RPG, COBOL and CL, when programming in the ILE environment. Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules.

Software tools can create modular code units from groups of components. Libraries of components built from separately compiled modules can be combined into a whole by using a linker.

Key Aspects

With Modular Programming, concerns are separated such that none or few modules depends upon other modules of the system. To have as few dependencies as possible is of utmost importance. Another key aspect is that when creating a Modular System, instead of creating a Monolithic application where the smallest piece is the whole application itself, one creates several smaller Modules which, when composed together, will create the whole system.

This makes Modularized Designed systems, if done right, far more reusable than a traditional Monolithic design since all or many of these Modules may be reused in other projects. In addition it also makes breaking projects up into several smaller projects through divide and conquer easier. Theoretically a modularized software project will be more easily assembled by large teams, since no team or team members are creating the whole system, or even need to know about the system as a whole, and hence can focus only on the assigned task. This breaks with the key assumption of The Mythical Man Month, attempting to make it possible to add more developers to a late software project without making it later.

While many will create Modularized Systems through using interfaces, others will swear to instead of relying on interfaces they'll solely send data around within the system so that no methods with explicit signatures even exist for communicating within the system (this aspect has gained a lot of ground in the last years due to that it at least seems to partially solve the "versioning problem" often experienced when using interfaces for communication between modules), for example: instead of having many interfaces for every time you want to communicate with another module, you'll end up with only one interface with only two methods; data Listen() and void Send(data)^{[citation needed]}. Notice that there are no reasons why one cannot use traditional programming languages to achieve modularized systems.

Often in extremely modularized software projects it will also be possible to send data out into the other parts of the system without even knowing who - if any - will ever be listening, and when receiving data, one also never knows - or shouldn't know - who actually sent the data in the first place.

Modularized Programming is a loosely defined concept. With no official definition, it is the programming technique of composing loosely coupled modules, and forming them together into a complete system. Where Modularized Programming ends, and Dynamically Linked Libraries, or even Object-oriented programming, start is probably in the eye of the beholder. Modularized Programming can to a certain extent be defined as the natural predecessor of OOP, or an evolutionary step on top of it.^{[citation needed]}

See also

• Architecture description language
• Cohesion
• Constructionist design methodology, a methodology for creating modular, broad Artificial Intelligence systems
• Component-based software engineering
• Coupling
• David Parnas
• Information hiding (encapsulation)
• Library (computing)
• List of System Quality Attributes
• Snippet (programming)
• Structured programming

References

1. ^ Multiple (wiki). "Modularity". Docforge. http://docforge.com/wiki/Modularity. Retrieved 2010-01-27. 

• O2 Software Process