– Book of Genesis – OO Bible

Abstraction is very important concept in OO. Understanding Abstraction is crucial in becoming a successful OO designer. Abstraction cannot be understood by reading books (which deal with it in Abstract terms turning it into a sort of mystery). Like Morpheus said to Neo in Matrix, You need to experience it yourself.

Roughly stated, Abstraction is the process of discovering classes, their responsibilties [the services they provide, the functions they implement] and how these classes interact [co-ordination] with others to complete the big picture [implement the system].

Continuing with our 'File System' example [easy to understand], it's easier to find Files, without using 'Search', if the directories are given meaningful names. Files an directories [ class/functions] are easier to find if the names are short and easier to remember.

It's easier deduce what files 'My Photos' directory contains, than the one named 'RoboXYZ12T45G'.File system [programming language] will not prevent a file 'hardrock.mp3' from being created under 'My Photos'. It's the users [programmer] resposibility to organize files [functions] under the right directory [class] based on purpose [responsibilty] of that directory [class]. To summarize, meaningful and easy to remember names ought to be given based on the purpose served.

The purpose a class serves [it's responsibility] comes from the Context in which it's used. If there are a bunch of functions that deal with managing a savings account in a Banking System, since they serve the same purpose [of managing an SB account] they should be grouped together under the class [meaningful name] 'SBAccount'. The name 'SBAccount' also serves to explain the purpose of the class. Being short, it's also easier to remember than 'BankOfSwaziLandSavingsBankAccountClass'.

The class names are easier to remember if they are based on some concept in the problem domain [ project requirements]. The usual practice is that 'Nouns' in a system become Classes and 'Verbs' [ like deposit/withdrawal] become functions. Of course, it's a gross simplification, it requires a thorough understanding of the domain [ Banking/Finance/Automotive etc.] to capture the REAL nouns and verbs. Domain expertise is highly critical in designing the system, in a meaningful and easy to understand way.

Not all classes are [problem] domain based. Some might come the language, technology, user interface, architecture, library and or the framework used. And others from the solution the designer proposes. For example, you find that 'Loan Approval' in bank is a sequential process with muti-levels of verification and approval. Workflow will be an ideal solution to handle this.

You might decide to to use off-the-shelf third party WorkFlow profuct (COTS) or develop your own solution. Eitherway you'd be likely to come across Classes like 'WorkflowDefinition', 'WorkFlowStep', 'WorkFlowStepsRelation', 'WorkFlowInstance', 'ActivityInstance' etc. There is no magic formula to these (so-called) 'Solution Domain Objects' as they are based on the solution proposed.

As often famously stated – 'It's an Art. Not a science'. That said, there is a veritable treasure-trove of pre-packaged/ready made solutions available under the name Patterns. [ mainly Design Patterns/Architectural patterns].  There's also a class of Patterns called 'Analysis Patterns' to assist in discovering classes in the Problem Domain too. A word of caution, Patterns are a highly advanced subject and difficult to understand for a beginner to OO programming. These should be read and refered only after coming to grasps with the basics.

For for most common programming situations, Patterns are an overkill ;  they add complexity to the system in exchange for flexibility. While flexibility makes the systems easier to extend, with lesser code change, it also makes it hard for the new programmer to understand the system and become productive in a short span of time [ high entry barrier]. It's my experience, many times [mainly newer] programmers use patterns to show-off [based on ego], instead of any real 'Flexibility' requirements. Most times it pays to 'Keep It Simple Stupid' [KISS]. If flexibility is needed later, simple code can be re-factored into Patterns to achieve the results.

It's a common misconception that great designs are arrived at the beginning using tools like UML, Rational Rose etc. It's pragammatic to start with a simple design and well-designed [problem] Domain classes. As the development continues Requirements will begin to make sense, REAL requirements will begin to surface, better understanding of the solution will develop, as also real world concerns like speed of execution, Robustness [ handing errors without crashing], Availability [ lesser downtime], Scalability [ ability to handle large number of users without serious degradation in performance] etc. begin to kick in. In a nut-shell, complete design of the system at get-go is a pipedream. Design is a evolutionary process. Most great designs are arrived at by continuous Refactoring.

Since the post has already turned out to be longer than intended, I leave the topics of Co-ordination, Inheritance, Normalization & De-Normalization to a future post.

Let me know your views.

First salvo was fired by Microsoft with the introduction of C# , .NET SDK and by allowing scripting languages as first-class citizens under .NET runtime, a privilige long denied to them under JVM thanks to SUN's limiting NBH (Not built here) vision. C# not only emulated Java's most successful features, but also came up with several handy features like Autoboxing/Unboxing, Explicit interface implementation, properties, variable arguments, friendly-for-loop and so on. SUN, which had been reluctant to add these much demanded features (by programmers), was finally forced to add these features with Java 5. The hurried introduction of 'genericity' before it's C# advent is a sign that Sun takes the threat seriously.

On the other hand, dynamic languages have grown in popularity, thanks to the success of PHP and newer OO languages like Ruby and Python. Though more focussed on Web development, the collective mindshare developed is significant, and considering most apps developed these days are indeed web apps, they indeed pose a serious threat to Java's dominance over server-based programming.

On the one hand SUN's marketing machinery gets busy dissing dynamic languages to be slow, lacking type safety and unsuitable for developing large systems. On the other SUN developers are busy adding native support for 'Scripting languages' with Java 6. Main focus will be to support 'Ruby' (despite reluctance to admit it) and PNUTS, a homegrown scripting language. If SUN's so convinced that scripting languages pose no serious threat, why's give a high priority to support them? And develop yet another scripting language ? (which incidently was developed by Sun's Japan division, coming from the home country of Ruby!) 

Countless flame wars have been, are and will be fought over internet about which language is the best, and likely to emerge the winner. Most of these discussions are political in nature and have nothing to do with the real merits/de-merits of the languages when it comes to the "in the trenches" programming. As a language-agnostic programmer, I believe every language has it's share of strengths and weakness. There is nothing you can do in one, that you cannot do in other. Some might need you to write lesser code, others more code. Some will run faster and others adequately fast.

Having said thus, I'm not ignorant to the fact that programming landscape is changing. Project budgets are shrinking, thanks to bad economy, along with project timelines due to cut-throat competition. Only those projects that get it right fast and able to change fast keeping with changing business dynamics will succeed in the unforgiving economy.

The reign of Moore's law over processing power ( CPUs getting more powerful and faster every year), has ensured the death of 'my complicated language is really fast' argument. It suffices if the language is sufficiently fast enough to meet business needs. Businesses will, continuingly, be less willing to invest in years of development (with associated huge costs) for the sole reason that the system will run a little faster. Especially, if there are other solutions available round the corner. When time to develop and market is critical to success, companies will look for good solutions that deliver faster, instead of execellent solutions that take longer to develop.

Days of throwaway and dummy prototypes is gone. Prototypes are expected to be built fast and easily convertible to the final solution. Dynamic languages have an edge over Static languages due to their flexibility, ease of development and ability to do more with less code. With the dropping hardware costs and increasing processing power, availability of native libraries to perform variety of tasks appear to be the final barrier. Of course dynamic languages also need faster VMs, for those occasions where the speed of execution makes or breaks the system.

In one of the discussions, Guido van Rossum (author of Python), when asked what would be his number 1 wish for his language, made a frank admission that it would be 'a Faster native VM'. All said and done, Java gained mainstream acceptance only after the success of JIT compilers and Hotspot VMs. In theory, there is nothing to stop development of Faster VMs for dynamic languages. In practice, however, few can afford legions of full-time dedicated programmers like Sun or Microsoft.

Sun and Microsoft opening their VMs may be a good news in the short term, in terms of faster VMs, availability of libraries and tools and wider acceptance. But in the longer run, it can turn out to be a curse too! Ready availability of Java/.Net libraries will kill motivation to develop native libraries. This could seriously hamper the growth of dynamic languages, limiting their usage to faster prototyping. Without a wide repertoire of libraries they will never be candidates for providing full blown solutions. Programmers would still be forced to interact with Java or C# for most functionality.

Other than opening JVM, it wouldn't surprising if a future Java version comes with scripting-like extensions very soon. Microsoft has already taken a lead in this direction with C# 2.0 (closures, partial classes etc.). I'm sure that Java will follow suit. It's very important for the native statically compiled language to be scripting-like, so that, if needed , crtical code in the scripting language can be converted, speedily, into the compiled language for performance. Being script-like will provide an easy migration path (feature to feature). And the addition of these features will also increase programmer productivity manifold in Java and C#.

 As I see it [as of now] Coding foward, most new functionality will be prototyped using lanaguages like Ruby or Python under JVM or .Net environments. Java and C# will be used for the libraries they provide. If the scripting code runs fast enough it will be retained. Otherwise the code will be converted to Java or C# for better performance, and some even to venerable old system-powerhorse C lanaguage too.

Cue : It will pay to know and be ready to program in multiple languages. Proficiency in at least one static, one dynamic and C language ( and remaining knowledgeable about others) will be the key to success.

Personally, I would prefer Java followed the Python way; allowing older features to co-exist through minor revisions ( like 2.x versions) and remove them with the next major revision (like 3.0). IMO deciding to take the leap (migrate) to next major version of a library, framework or platform is a non-trivial decision, considering the large number of feature changes involved. And that's what major revisions are for!

To clarify further, let's say I migrate my Java app from JDK 1.4 to JDK 5.0. For e.g. If I am still using the Collections, old style, without generics, don't utilize new for-loop and auto-boxing/unboxing to make the code less cluttered, what benefit do I reap by using latest and the greatest version? I would be better of sticking with 1.4 version for some more time (as long as it's supported)

Most migrations to next major version happen, NOT because the project wishes to use the new enhancements, but to remain saddled with the latest supported version. Given this reason, if Sun were to totally remove all deprecated methods from since the last major version, projects would still migrate. And in the process enjoy the benefits of using newer/advanced features.

But, that's the last thing SUN is likely to do. It would takes months for 1.4 projects to use 5.0 (which they ultimately will!), meaning longer support period for 1.4 and a more protracted adoption period for 5.0. It would be more easier to mark stuff 'deprecated' and move on,  achieving 80% adoption within months.

It's not that SUN has a pristine record for backward-compatibility. Just try running EJB 1.0 apps in latest servers. EJB 3.0 deprecates most of EJB 2.0 way of doing things ( Entity-Beans no longer exist!). When SUN can come up with such massive deprecations at an Enterprise level, how come SUN's so fanatic about retaining deprecated JDK functionality?

First of all, the flawed versioning system. While Java was at version 2.0 (Java2) JDK version was kept pegged to 1.2. And now that Java is at version 5.0, JDK uses an internal versioning of 1.5. I can understand Java 2 situation, adding static/inner classes [of various flavors] might be forgiven for not bumping up the JDK version.But, if adding features like generics, enums, new for-loop etc. don't appear to warrant a major JDK version changes [in their thinking], I don't know what-else will?.

Secondly, the complacency caused by the @deprecated JavaDoc tag. It's cheap to use. I've seen used for trivial name changes [ l-o-o-o-nger names], addition of newer better methods, addition of parameters etc. While it's extensively used, it seldom serves it's purpose. More often than not, compiler warnings tend to be ignored; given the project deadlines and budgets. Deprecated methods keep building over time and soon it becomes near impossible to remove them as there could be countless projects using them ignoring the warnings. If SUN were to remove all the deprecated methods in the next version of JDK, it would be months (if not a year) before that version gains acceptance as mainstream.

IMO @deprecated is a half-baked measure that could have been used better. There is no standard way to capture when the deprecation happend (which version?), upto to what version the method will be kept, and when shall it be removed. For e.g it could've been -

@deprecated  since(1.1) allow_upto(1.3) removal_plan(1.5)

For versions prior to 1.3, say 1.2, the compiler could issue a warning ' Deprecated since 1.2. Will be removed in 1.5'.  For version 1.4 compiler should stop with the compilation error 'Deprecated method disallowed after version 1.3. Scheduled for removal in version 1.5'.  This will cause a slight heart-burn, but it will also ensure that dyed-in-the-wool slobs stop using those features. On reaching 1.5 the feature can be safely removed.

Wouldn't it make the life easier for all of us?

@depecated Deprecated by @Deprecated

 @deprecated tag itself has been deprecated by @Deprecated annotation since Java 5. Now you need to give @Deprecated annotation to inform the compiler of code deprecation, and @deprecated JavaDoc tag to add reaons of deprecation to JavaDocs. How ironic, that the venerable feature itself should become an example of 'Deprecation' and the redundancy/code-bloat it causes.

The confusion is further confounded by OOAD books that teach in abstract as in 'In procedural programming functions call functions. In OOP Objects pass messages to other objects'. What  this really means is Objects call functions defined within their own class or in other classes!

Lets consider an example .

Procedural function call --

As you can see from the above example, Objects do most of the work in OOPS. Objects need to be created (using 'new' operator) to be able call the functions (methods) on them. Once an object is created multiple functions can be called on it. An object can, not only call it's own classes function, but also create/and or call other objects [of same or different class] functions.

Though, at the outset, this style of programming might feel radically different, at a micro-level OOP is procedural too.

public class MyClass {               

public void Myfunc() { f1(); f2(); f3(); }                

private void f1() { // do stuff }                

private void f2() { // do some other stuff }                

private void f3() { // do some more stuff }               

}

As you'd notice, implementation of Myfunc() is entirely procedural. Good thing about OOPS is that builds on best practices of POP, while eliminating it's limitations.

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.

Actually Object-Orientation is a very simple programming paradigm, once you come to grasp it. So it should be really simple to learn and master OOP. However, in reality, things are not that peachy. Unfortunately, most of the widely available so-called 'Object Oriented Analysis And Design' (OOAD) are either utterly useless in understanding it, or make it appear like complicated rocket science through liberal zargon-dropping.

There are honorable exceptions like Bertrand Myer's seminal book 'Object Oriented Software Construction', which IMO is, a must read for every OOP programmer (even if he/she never intends to program in Eiffel, the programming language used in the book).

Given the lack of real good OOP books in main-stream languages (most of them deal more with language features instead of teaching OOP), it's not suprising to see appalling lack of Object orientation, years after OOP has gained popular acceptance. A lot of it has to do with the half-baked truths propogated by the 'Learn X langauge in 10 days' books.

With all due respects, I agree that, these books do help a beginner to learn a new lanaguage's important features quickly. But they also present half-truths as the reasoning behind how certain features are to be used. While an experienced programmer knows well to ignore them, they could be (and are) taken as cardinal truths by newbies.

This misunderstanding of OOP by beginners (as well as some senior) programmers is the cause of plethora of badly-written programs that do not run as intended, crash and cause losses to the customers. DailyWTF (http://thedailywtf.com/) is a great source for these programming gotchas. It's a great forum to read, not to mock at others, but to learn from their mistakes and prevent ourselves commiting those same mistakes under project (deadline) pressure. Or the influence of "star" programmers/designers who believe theirs (only) is the best programming methodology in the whole world, however tedious and silly it might be.

You're right , if you guessed, the Roman Numeral "I" indicates it'll be one long post that'll be broken down into manageable digestible chunks. Having dealt with the reasons behind highly prevalent misunderstaning regarding OO among programmers, future installments will cover the popular misconceptions and try to correct them.

Yours, De-Coded

No, NOT Yet Another Programmer blogging about his girlfriend or his latest thingamajig. Why would that be of any interest to you? Unless you lack "life" and have all the time in the world to kill, reading trivialities, which I suspect isn't the case if you continue to read.

Yes. This blog is about Coding. More about Coding techniques that work and that don't (per my experience). Design, Architecture and other buzzwords will be peppered in as needed; but - Coding – shall remain the crust.

The focus will be on techniques, rather than Programming Languages. I remain agnostic to wasteful discussions about 'why a particular language/OS is better than others?'. My personal mantra – Any OS/language is okay, as long as it gets the job done satisfactorily. Having said thus, I am a bit biased toward Open Source/Free software as they provide full source code to the implementation; enabling programmers like me to tweak, change, enhance the system per our liking. What better way to judge a entree than having an up and close look at it's recipe? And garnishing can be added if you, so, desire.

Why am I doing This? Too much time to kill? Obviously, NO. You wouldn't find any personal pics or boring mundane details here. And no "hot" scoops either. Well, I am doing it for myself. A self-referential guide to nudge me, back, into the right path whenever the project pressures shall lead me astray.

I will be glad if you find any of it useful, and grateful if you contribute you thoughts and indebted if you'd correct me and/or provide a better solution or analysis.

My Thanks to K & R for providing millions of Coders the right tool to learn programming and programming languages. Also a nice way to begin a blog.

Yours, De-Coded