Philosophy of Modular Programming

When you are assigned to modify a huge piece of code and all of its functionality in a single file you begin to question your profession. How even, I am going to modify this? Even before that, how even is it possible to understand this? Modular programming came to rescue.
Life becomes much more simpler when we try to loose couple our relations with objects defined in the real world. It becomes much more easier if functionality is adaptable, modular in nature and assembled with similar functionalities. This is true as well when are developing software. Taking a simple example from our day to day life, washing clothes at my home. You can wash it by hand but this will be highly manual effort. Consider this, a new module is introduced to make your life easier, a Washing Machine. All the similar functionalities required for washing clothes are available with Washing Machine. It has everything one can wish for to make it loose coupled. You just need to know the interface and not its implementation or factory method(manufacturing method or brand). You can place it where ever you want irregardless of platform, a house or laundromat.
This appliance, Washing Machine, is a module available in my home to perform daily task of washing clothes. A module is a software component or part of a program that contains one or more sub routines. And one or more of these independently developed modules make up a program. Developers assemble all the similar functionalities in a single module for better maintainability and usage.

But you may ask, why should I care to learn about Modular Programming? Why do we need multiple modules? Why are all these modules are loose coupled and how are we going to maintain the bigger solution? Why can't we focus on making one simple module to solve all of our problems? Why is it needed in understanding the bigger picture? All answers can be consolidated in this post.

Philosophy in Code

Knowingly and Unknowingly Software Developers work or develop modular programs. In functional programming paradigm, developers treat function as first class citizens and call them in flow/routine. These called functions perform required task to makes life easier by better maintainability and calling them is similar to calling a module from a piece of solution. Hence, here I present, the Philosophy of Modular Programming.
There are a set of principles defined in this Philosophy of Modular Programming. Of all I am going to mention 4 major principles with some piece of code to have a better understanding:

Principle 1: Allow Modularity

A well defined segmentation of the project effort ensures system modularity.
This is to afford the changes brought by scope of further improvements, feature additions and flexibility to change/remove the existing modules.

import my_home
assert my_home.modularity==True

Taking a real life example, suppose I am working on project to build my home. I want to ensure in future that I do not stick with the modules I have installed during original build. These modules might wear off with time, or I might need some new functionality. So I ensure that I have a flexibility to add/modify or remove the existing modules.

Principle 2: Distinct Functioning Module

Each task forms a separate, distinct program module. At implementation time each module and its inputs & outputs are well defined. Also there is no confusion in the intended interface with other system modules.

from my_home import washing_machine as washer, dryer
assert isinstance(washer.wash_clothes(ip_clothes),Washed_Clothes)
>>> "Washing Clothes using Washing Machine"
assert isinstance(dryer.dry_clothes(ip_clothes),Dry_Clothes)
>>> "Drying Clothes using Dryer"

While using appliances like washing machine and dryer as module from my home, I will ensure they perform their own functionalities. I will also ensure that I am aware what this module is capable of, I only provide required input, clothing material here and not anything else. If not, then either I will not be able to operate it, or break functionality of my module. Eg throwing a brick in the washer. Woah, wild idea, eh?!

Principle 3: Independent Testing

At checkout time the integrity of the module is tested independently.

from my_home import washing_machine as washer, dryer
washer.integrity_test()
>>> "Washing Machine Works fine. All Test Passed"
dryer.integrity_test()
>>> "Something wrong with Dryer. Please check functional display
 or Contact Customer Support"

Before installing any appliance in my home, every appliance should be tested independently. This module should not be defected in any functionality. Suppose, before buying a Dryer you check all its functionality and make sure its working fine as a module.

Principle 4: Modular Maintenance

The system is maintained in modular fashion; system errors and deficiencies can be traced to specific module system, thus limiting the scope if detailed error searching.

from my_home import washing_machine as washer
washer.wash_clothes(bucket_of_clothes)
>>> Connection Error: Power is not available. Traceback (most recent call last):
>>> --->2 washer.wash_clothes(bucket_of_clothes)
>>> --->67 my_home.washing_machine.check_power()
>>> --->123 my_home.utils.is_main_power_available()

If my Washing Machine breaks down in the middle of task, I need to identify the root of the problem. If I had just a single module, ie my home, I would have concluded my home broke down. But that's not the case. Breaking down the my into different modules has helped me to track down, it was just the issue of main power. Thats the beauty of modularity introduced while building my home.

Decomposing a solution or a project into right modules will make your Software Development Life Cycle (SDLC) much more easier. You can add or modify any functionality required or not required while being able to maintain the functional integrity of each and every module.
In the next write up, I will discuss on which criteria one can decide to decompose System into Modules.
If you liked my content don't forget to provide a clap. And if wish to discuss further about Software Engineering and Data Science, ping me on LinkedIn.