De-Coded

In the beginning there was Abstraction. And the abstraction was God (of OO). And God of abstraction said let there be Classes and there were Objects

– 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.