Content

Programming: The downsides of Modularity

Page is part of Articles in which you can submit an article

written by owen on 2009-Jun-04.

There is a common misconception that modularity is inherently a good thing.  In fact modular systems are not optimized for performance and are often harder to maintain depending on the extent of the modularization.  It is similar problem as OOP which as a drastic effect on the program as a whole.  Once a modularization technique is chosen it usually affects the entire program, permanently crippling it if it is not properly implemented/controlled.   Modularity similar to OOP is a useful tool in the appropriate context. One should not start writing a modular program.  However one should anticipate the areas of the program which will benefit from being modular.

Lets us look at a simple example 1;


start program
        print("-- Add 2 numbers --");
        print("Enter first Number:");
        firstnumber = readkeyboard();
        print("Enter second Number:");
        secondnumber = readkeyboard();
        
        result = firstnumber + secondnumber;
        
        print("Result:" + result);
end program

As you can see the Example 1 is pretty simple and efficient.  What I'm going to do now is redesign the above program in deferent stages of modularity.  What you will notice is that as the program becomes more modular it becomes more complicated and at the same time less efficient.

Lets us look at example 2;


function acceptnumber( screenmessage ) 
     print( screenmessage );
     return readkeyboard();
end function

start program
     print("-- Add 2 numbers --");
     firstnumber = acceptnumber("Enter first Number:");
     secondnumber = acceptnumber("Enter second Number:");

     result = firstnumber + secondnumber;

     print("Result:" + result);
end program


In example 2 we have introduced a function called acceptnumber() which allows us to reduce the amount of lines in the main program by moving the repeat tasks of printing a message on the screen and reading the keyboard from the user.

Lets us look at example 3;


function acceptnumber( screenmessage ) 
     print( screenmessage );
     return readkeyboard();

end function

function do_addition( num1, num2 )
     return num1 + num2;
end function

start program
     print("-- Add 2 numbers --");
     firstnumber = acceptnumber("Enter first Number:");
     secondnumber = acceptnumber("Enter second Number:");

     print("Result:" + do_addition( firstnumber, secondnumber ) );
end program

In example 3 I've moved the code that does the add calculation into its own function called do_addition.  do_addition accepts the 2 numbers that need to be added and returns the result. I've also go ahead and gotten rid of the result variable since its not really used for anything important.

Lets us look at example 4;


constants = array ("-- Add 2 numbers --", "Enter first Number:", "Enter second Number:", "Result:", "addition" );
function acceptnumber( screenmessage ) 
     print( screenmessage );
     return readkeyboard();

end function

function do_addition( num1, num2 )
     return num1 + num2;
end function

function get_data_input(settings)
    print(settings[0]);
    input1 = acceptnumber(settings[1]);
    input2 = acceptnumber(settings[2]);
        return array( input1, input2 );
end function

function get_calculation_output(settings, data_array)
        if( settings[3] == "addition" ) {
                return settings[3] + do_addition( data_array[0], data_array[1] );
        }
        return "no work or invalid settings";
end function

start program
        data_array = get_data_input(settings);
        output_text = get_calculation_output(settings, data_array);
    print(output_text);
end program

In the 4th and final example I when all the way and separated the input of data from the output and calculation. You maybe able to see various advantages and disadvantages of this method but it was done to demonstrate my final conclusion.

Conclusion

As you can hopefully see, all four examples do exactly the same thing, except each one becoming increasingly modular, less efficient and more complicated. I could have done a 5th step and implemented it in OOP but by now you should be able to see my point. A program can be simple without being modular and on the other hand be modular but VERY complicated. A program being modular does not mean that it is simple. And a modular program is not necessarily more readable than a simple program.

permanent link. Find similar posts in Articles.

comments

  1. Owen, why did you go out of your way to annoy me this morning? Not optimized for performance? Harder to maintain? Those are big claims that you don't back up. with anything but some toy examples. Yes, if you apply three levels of modularity to a nine line program then the result will be unnecessarily complicated. Wow, big news, stop the presses!!!

    Modularity is inherently a good thing, in the same way that nutritious food is inherently a good thing, but that doesn't mean they can't be abused. Try writing and maintaining even a small program, say about 10,000 lines, with little or no modularity and see.

    by Stewpeas 2009-Jun-05 

  2. I don't know what world you live in but 10,000 lines of code is not a small program. The "toy" examples show how the program degrades from its original design because of ignorant changes.

    by owen 2009-Jun-05 

  3. I agree... 10,000 lines of code is by no means small. Still, I am a fan of modularization.

    by Mad Bull 2009-Jun-06 

  4. I exaggerated slightly for effect, in the world I live in 1,000 lines is small, and 10,000 is medium to large. However, my point still remains, your examples have shown how a toy program degrades when you apply excessive modularity to it (what does that prove?).

    by Stewpeas 2009-Jun-08 

  5. the only way I could make the article hold on a page if i used a example that people can understand. You could always multiply the simple program by 10, lol. The conclusion of the article is the point I;m trying to make.

    by owen 2009-Jun-08 

  6. ...that proves that the way we are taught is not consistent with what will be expected of us as software developers.

    Concepts such as modularity are taught early in year one, where a 'simple-program' is modularized. So, effectively we are formally trained to over-modularize simple programs.

    I think the article is valid and effective in demonstrating this.

    Modularizing is a tool to attack complex problems. When used on a simple problem, modularizing itself will add that level of complexity.

    by kodeci 2009-Jun-10 

  7. Thanks, I appreciated your article. Although how can you tell in practice if code is overly-modular? At what point should you split a long function into several smaller ones? Should you split code only when it reduces repetition? Or...?

    Simon.

    by Simon 2009-Jul-08 

  8. It is often up to the experience of the programmer to determine under what conditions to modify the code. Use if its not broken, they is no real need to make the code "pretty" unless you have extra time to fool around with it.

    Reducing repetition (code reuse) is the main reason for splitting code in functions.

    Often times long functions are simply just "long" and don't have to be split up. Plus you don't want to split a single long function into many stupid little functions that only gets used by one parent function.

    by owen 2009-Jul-08 


comment