Modular Programming & Header Files

When people spit out “Modular Programming”, “Component Programming”, they mention “DLL”, “COM”, “Bundle” and so on.
They mostly talk about how to make module.

Well.. in my opinion it is not important. It is how to package a group of source codes basically. What is more important is how to think code elements like implementation files, header files and conceptual element like classes, structures, keywords, macros in modular way.

Different between procedural programming and OOP is that whether they are verb-centric or noun-centric. In procedural programming paradigm, you write codes like telling a story. However in OOP paradigm, you first creates actors and actresses, objects like trees, cars, buildings. After doing so, you let them interact one another.

OOP is more modular, because you can take one object from one project and put it in other project easily. Well-designed object is self-contained. So, it is possible.

Even when you write codes in C or functions, you can make them rather modular than procedural. If you divide functions in the unit of thought, you can make them modular.

However, I noticed that many people don’t think modular way and even when they write codes in C++, all modularity is gone.

What do I say? Let’s take a look at this.

In an “A.cpp” file you write this.

#include <one.h>
#include <two.h>
#include <three.h>

In three.h, you write this.

class CThree
    COne *mOnePtr;
    CTwo mTwoInstance;

Can you see a problem? Yes. In three.h, it uses COne and CTwo without including their header files. The original author thought it was OK because in A.cpp, which used COne, CTwo and CThree, one.h and two.h were included. Well.. well… what can I say….

It is very bad practice, because you will have compile-time error if you decided to use CThree class in other implementation file without knowing that you should include one.h and two.h first.

This causes big problem in big projects which didn’t written by you. When you are hired by a company and assigned to some project, if you starts working on that kind of source codes, it can give you big headache.

This is an even worse example.

one.h is

#include "another_one.h"

class COne
    CSomething *somethingPtr;

This is another_one.h header file.

class CAnotherOne
    COne oneInstance; // This line references a class which is not yet declared/defined.

In another_one.h, there is even a hidden problem.
The oneInstnace is declared as static. ( I don’t mean “static” keyword. I mean the static in static vs. dynamic. )
Why is it a problem? If you declare it dynamically like :

COne *oneInstancePtr;

you can forward-declare the COne like :

class COne;

class CAnotherOne
    COne *oneInstance; // This line references a class which is not yet declared/defined.

However, because it is in static, the COne should be defined.
Then you should include “one.h“. It will make it cyclic inclusion of header file.

one.h -> another_one.h -> one.h

Including header files like above makes codes very un-modular. You can’t freely move the headers/sources to other projects and can’t use them as freely as you wish.

However, I noticed bunch of this kind of codes in a project I currently work on.

So, why do people interview programmers when they hire the programmers? Knowing some terminology, remembering how to implement list are not the most important things.

ADDED : In short, header files should be SELF-CONTAINED.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: