Programming: The downsides of Modularity

[owen]

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 is not properly implemented. 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.

[bu]Lets us look at example 2;[/bu]

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.


[bu]Lets us look at example 3;[/bu]

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.


[bu]Lets us look at example 4;[/bu]

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.

[bu]Conclusion[/bu]

As you can hopefully see, all four example 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 seem 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 modular program is not necessarily more readable that a simple program.

original article / permanent link

[Nestersan]

Nice article...very informative.

[Skele Drew]

My take: Modularity isn't something to be used in every programming case. The main purpose of modularity IMO is to make source code more easily read (seeing that there're compilers that automatically inline many of these methods for optimization), and not always to improve performance.

In a simple program, there isn't really any need for modules since the code can be easily read. But how does one define a "simple" program? An assembly routine? Or a script? We need to consider that any high-level language and above is made of many library modules. All things considered, a truly simple program doesn't do much. It's when it's combined with other simple programs that it can really work. It's these simple programs that make a module.

So basically modules have several main advantages including code reuseability (prevents wheel reinvention) AND complexity reduction. I think the author of the article has mis-defined a simple program to mean something approaching a bit of C code or something similar.

A simple program can only be truly defined at the machine level. And that's how I see it.

[psilos]

... I think the author of the article has mis-defined a simple program to mean something approaching a bit of C code or something similar.

Owen is the author of the article so take the opportunity to have a healthy debate as it is rarity when you actually have a chance to speak with one instead of just cursing them in your mind when reading an article or textbook and wishing you could argue your point about them being only partial correct, blatantly wrong or pure genius.

[owen]

the phrase "simple program" is more figurative than literal. Its is not really the amount of code but how easy it is to explain and predict. basically this;

For a program to qualify as simple, there are several benchmarks:
Its operation can be completely explained by a simple graphical illustration.
It can be completely explained in a few sentences of human language.
It can be implemented in a computer language using just a few lines of code.
The number of its possible variations is small enough so that all of them can be computed.

http://en.wikipedia.org/wiki/Simple_...imple_programs

In fact a truly simple program DOES exactly what it needs to do. No more or no less.

[digimon]

Why i mostly support modularity is because My projects are normally large and functions are often reused all over the application. SO as much as we have two simple function up there, u will be surprised how many other places they get called and how often.

I support the first set of examples,

THe 3rd-4th example however, is an overkill.

So basically, if it is a small solution then we should try not to do things like an API style too much. But as for large apps, best to modularize than to search 15,000+ lines of code/ stored procedure calls/ etc

[owen]

While it may seem like I'm hating on Modularity, I'm really not, I'm pointing out the disadvantages. Disadvantages which are never really explained to most people in programming and management. A modular program is not the same as a simple program.

Examples 3 & 4 are there because they make sense if you want to expand the program into something like a full calculator, its not over kill but more of a logical path that a progammer would take if he/she was planning to write a calculator program. however a programmer should never start at step 4 because if you teach people to start at step 4 they will never be able to go back to step one because the point gets lost in the 10,000 lines of code that step 4 will give you.

[angeleta]

Why i mostly support modularity is because My projects are normally large and functions are often reused all over the application. SO as much as we have two simple function up there, u will be surprised how many other places they get called and how often.

This is exactly what we were taught in college (mind you i am not a programmer and i hate programming) but modularity as far as i know is just to avoid repetition (redundancy etc)...so if i needed to call that function somewhere else in my program it would've been easier to use modulars, right? I think its really a case by case basis, nuh tru?

however a programmer should never start at step 4 because if you teach people to start at step 4 they will never be able to go back to step one because the point gets lost in the 10,000 lines of code that step 4 will give you.

Are you referring to formal training? I am sure they teach you from the basics...at least thts what i rem...i didnt learn abt modularity until late in my course....but then again, mayb times have changed...

[Skele Drew]

While it may seem like I'm hating on Modularity, I'm really not, I'm pointing out the disadvantages. Disadvantages which are never really explained to most people in programming and management. A modular program is not the same as a simple program.

Examples 3 & 4 are there because they make sense if you want to expand the program into something like a full calculator, its not over kill but more of a logical path that a progammer would take if he/she was planning to write a calculator program. however a programmer should never start at step 4 because if you teach people to start at step 4 they will never be able to go back to step one because the point gets lost in the 10,000 lines of code that step 4 will give you.

Your point is well taken. But I don't think it'd be really possible to modularize a simple program anyway. A truly simple program should do a single, simple task. Period. There's no way a "simple" task can be broken into smaller bits.

Once you hit examples 3 & 4 (even #2 to some extent), you're no longer dealing with a simple program. And one more thing. Any programmer who hasn't experienced some spagetti coding (remember the infamous goto + labels?) or other and felt the burn hasn't really programmed yet IMO .

[owen]

This is exactly what we were taught in college (mind you i am not a programmer and i hate programming) but modularity as far as i know is just to avoid repetition (redundancy etc)...so if i needed to call that function somewhere else in my program it would've been easier to use modulars, right? I think its really a case by case basis, nuh tru?

Are you referring to formal training? I am sure they teach you from the basics...at least thts what i rem...i didnt learn abt modularity until late in my course....but then again, mayb times have changed...

"Modulars" is not a word. This article is about the disadvantages of modularity.

Your point is well taken. But I don't think it'd be really possible to modularize a simple program anyway. A truly simple program should do a single, simple task. Period. There's no way a "simple" task can be broken into smaller bits.

Once you hit examples 3 & 4 (even #2 to some extent), you're no longer dealing with a simple program. And one more thing. Any programmer who hasn't experienced some spagetti coding (remember the infamous goto + labels?) or other and felt the burn hasn't really programmed yet IMO .

You'd me surprised how many simple programs are done this way. Examples 3 and 4 do exactly the same thing as 1 and 2 except they are a bit more modular which is the point of the article. An article without a point is useless.