INGRESS:

Module – off late is the abused and loaded software term in various contemporary languages and frameworks (like C#/JAVA, Angular1/2, ECMAScript 6/Typescript 2). The more it is laden with contextual meaning and syntax, the more it gets convoluted. This blog attempts to remove the murkiness and give a concise clear understanding and assumes that you have a working knowledge of popular languages & framework that is used to elucidate here.

TIME TRAVELING:

Traditionally modular programming is a terminology used to represent the effort of giving structure to any software code with a lofty intention of higher cohesion and decoupling the functionality, which eventually benefits the programmers in moving around the encompassed code chunks of the module without any dependency or attachment. In this way, the modules are isolated and reusable.

Excerpt from www.c2.com:

• Object-Oriented programs are usually modular. Modular-Programming does not have to be Object-Oriented. The difference is that “merely” Modular code does not need to be associated with data (at least the way Object-Oriented code is structurally associated with data.)

The inference I gather here – modular programming can be described as a technique that organizes code into definitive, independent, interchangeable, cohesive structure. In a general sense, the module is a means to organize code but there are subtle connotations to this in each language and framework that we are planning to discuss today.

DISAMBIGUATION:

• C#: Modules are implemented through building Assemblies (a crude definition of assembly would be – software libraries with metadata that describe the contained code + versioning ability etc.) There can be more than one C# file in an assembly and each file can have more than one class. Note here that namespace is a means to separate group of classes inside an assembly through logical boundaries and has nothing to do with modular programming.
• JAVASCRIPT (ECMA5): ES6 doesn’t have an innate way to define modules but we can imitate. Before getting into the crux, I would like to give a mini-tutorial on scoping in JS – “JS is function level scoping language and unlike C# and JAVA, where it is block level scoping”. Every execution of a function creates a tiny scope for itself and if there are nested functions, then there are nested scopes too. The below code snippet kind of executes an anonymous function expression and in that process assigns the Math object to the global window – which is accessible application wide. For simplification of example, I haven’t implemented prototypal inheritance here.

• JAVASCRIPT (ECMA6): Not only do modules in es6 (which introduced the keywords “export” and “import”) allow the programmer to organize the code, it goes an extra mile by easing the onus of methodical eager loading the files in the client browser engine. Though ideally, the browser has to do the loading, we are just not there yet in terms of inherent browser features and hence we have a variety of module loaders (on the client side) like the popular ones are CommonJS / SystemJS. Each module can be roughly equated to a file and a file can have more than one class or function eligible for export. There was a period when the programmer has to manually check the order of JS files before dropping the link in the index.html or build tools like grunt/gulp.

• ANGULAR1: Modules in Angular1 can be mere consolidation or grouping of controllers, directives, filters, services/factories etc.
• ANGULAR2 / TYPESCRIPT2: Apart from the es6 modules, Angular2 has its own module represented by keyword @NgModule (refer the official documentation link) – this can be roughly equated to Angular1 module. But Angualr2 is more of decorative / annotation based and not syntax driven like Angular1. Note that there are still es6’s import and export keywords of es6 actively employed but to transcend es6 modules into the Angular world or boundary we need @NgModule. A NgModule is a class decorated with @NgModule metadata.

*Which does the following:

• Every Angular app has at least one module class, the root module. You bootstrap that module to launch the application.
• Declare which components, directives, and pipes belong to the module.
• Make some of those classes public so that other component templates can use them.
• Import other modules with the components, directives, and pipes needed by the components in this module.
• Provide services at the application level that any application component can use.

*Citation from official documentation

EGRESS:

We have taken a survey of the definition and delved into the syntax of the popular languages out in the current world. I conclude that though the keyword module is generically used to represent the idea of chunking clusters of code, there are nuances in each language and framework.

CODERS ARE CREATORS TOO!