De-Coded

My last post dealt with reasons why OOPS is misunderstood by a number of programmers. Having dealt with the cause, lets cover the effects.

Myth I : OOP is all about re-usability.

Fact : You don't need OOP to write Re-usable code. Good coding practices result in re-usability (OOP or not). OOP is all about managing complexity.

Recipe for Re-usability 

It's possible to write re-usable code in non-OO languages such a C or Pascal. Let's say you wrote a function to calculate factorial of a number, it is re-usable, in the sense, that it can be called from thousands of other places.

Any procedural function is re-usable as long as it depends only on it's parameters and doesn't depend on global data. To be really re-usable, the function must do only one thing and do it good. Don't attempt to do too many things in a function. If your function does that it's time to split (re-factor) it into two or more smaller functions. The term "modularity" is often used to refer to this practice of splitting code into smaller manageable chunks.

Also, it's a good coding practice to keep the length of a function limited to within 50 lines (max). If it exceeds the limit, chances are you are doing too many things there. Even if you're doing just the one thing, it probably involves several steps. It might be a good idea to refactor related steps into functions of their own.

A side-effect of modularizing code is the creation of global variables. It's always not possible to pass data around functions using just the parameters; definitely not if the functions need to pass around 10 or more parameters! Function calls with more than 10 parameters are difficult to understand, error-prone ( disordering of values passed) and maintain.

Having too much "Global Data" data is bad. It forces every function to depend on others thereby turning them un-reusable. It's also error-prone and hard to maintain. Now, before we shower praises on OO languages about the private variables, it would be sobering to remember that, a POP language like. C had static variables which limited visibility to only functions defined in the same file. For arguments sake, it's possible to declare all variables as public, for sake of convenience, the way externs (the real global variables) were abused in C.

What about extensibility? Simple. Use delegation!. Write another function that calls your function with additional functionality. In fact, as it turns out, delegation happens to the way to extensibility even in OO languages, in far more situations than the much hyped (and abused) "inheritance".

Managing Complexity

I hope the defence of PO languages didn't give the impression that OO languages have no or limited benefits. That would be far from the truth. In fact OO languages do enjoy distinct benefits over procedural peers. Otherwise they wouldn't have (nearly) overtaken the programming world!

While it's considerably faster to develop an application using a procedural language, systems developed using OO languages are easier to maintain and extend. The real secret being their ability to ease complexity.

If you have read any OOAD book, you'd most likely come the statement 'Human mind can at a time process only 7 plus or minus 2 pieces of information'. And forgotten by the time you read through to the end. Unfortunately, most authors don't elaborate further on the subject, leaving it out as a mundane detail.Instead of discussing in abstract terms, it would be easier to understand in terms of an analogy. Most appropriate would be to compare it to the File system in any operating system.

Any respectable OS has a file system that has a 'Root' directory (top-most directory). Root directory several directories underneath it, these in turn have sub-directories that contain sub-sub-directories and so on and so forth. This arrangement makes it easier to organize things by keeping related files together under the same directory. Having well-known directories ( like 'My Documents' in Windows or '/usr/' in Unix) makes it further easier to find things.

It also avoids Name-collisions. Let's say File Systems lacked the concept of directories and everything were stored under Root, it would be impossible to create a file 'xyz.doc', if a 'xyz.doc' already exists. The solution would be to rename as 'xyz2.doc'. Problem is you'll soon have a large number of similarly named files soon ( making it harder to find required info fast). The file names will continue to grow and become cryptic.

And soon will reach File System limitations on the length of file-names (256 on Windows)! Even if name-collision were not a problem, finding the one *single* file needed, would be like searching the haystack for a needle ( Root would have thousands of files under it, directly).

Procedural languages suffer the same problems as a File System with no directories. OO languages make it easier to organize things by having Classes ( equivalent of directories) that contain methods/functions ( files). Classes help in keeping the functionality better organized, so that functions that perform a certain task can be easily located (found) during maintenance. Name-collision is be avoided by having similarly named functions [which work differently] under different Classes.

Some OO-languages carry the concept further, through usage of Name-spaces(packages if you program Java). Name-spaces help to further organize classes logically (also physically in Java). It's the same concept as having sub-directories, sub-sub-directories etc. It's interesting to note that Java's support of Name-spaces in fact depends on using directories to organize classes. It goes without saying that languages that don't support name-spaces suffer a major limitation.