Modular programming

From Wikipedia, the free encyclopedia

Programming paradigms

Agent-oriented Component-based Flow-based Pipeline Concatenative Concurrent computing Declarative (contrast: Imperative) Functional Dataflow Cell-oriented (spreadsheets) Reactive Graph-oriented Goal-oriented Constraint Logic Constraint logic Abductive logic Inductive logic Event-driven Service-oriented 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) This box: view • talk • edit

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. 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.

[edit] Key Aspects

Some of the key aspects behind Modular Programming is the ability to be able to separate concerns such that none or few modules depends upon other modules of the system. To have as few dependencies as possible is of outmost 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, of done right, far more reusable than a traditional Monolithic design since all or many of these Modules will be possible to reuse in your 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 easier to have large teams assemble, since no teams or team members are creating the whole system, or need to even know about the system as a whole, and hence can focus purely on only that one task at hand they've been assigned. This breaks with the key assumption of the book Mythical Man Month in that it creates an environment where it actually is possible to add more developers to a late software project without making it later, which is the key quote made famous from the book The Mythical Man Month.

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 exists 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. Notice though that there are no reasons why one cannot use traditional programming languages to achieve modularized systems, the way to think about it is that 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)

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 are however a loosely defined concept, and there exists no official standardized definitions about what exactly it is, except that it's a programming technique that enables loosely coupled modules to be composed together to form a complete system. So where Modularized Programming ends, and Dynamically Linked Libraries starts or even OOP starts is probably in the eye of the beholder.

Modularized Programming can to a certain extend be defined as the natural predecessor of Object Oriented Programming, or an evolutionary step on top of it.

[edit] 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

[edit] References

• [O2 Software Process]

This computer programming-related article is a stub. You can help Wikipedia by expanding it. v • d • e