Thursday, August 24, 2006

Do not call virtual functions from the constructor

It is a best practice that we should not call virtual (abstract in Java) methods from the constructor. But why should we not?

Link to this article:

Wednesday, August 23, 2006

Closures in Java

Recently there has been much talk about whether closures should be introduced in Java. Many programmers who started with Java as their first language may not know what closures are.

Martin Fowler has a very nice explanation on his bliki.

Initially when Java was being designed there was some debate on whether Anonymous Inner Classes should be allowed to access non final local (method) variables. Eventually the feature did not make it in, but had it, then an anonymous inner class would have been almost a closure except that it goes against Martin Fowler's principle that languages that support closures should allow you to define them with very little syntax.

Monday, August 21, 2006

Informal web based learning

Would you like to engage in web based informal learning, rather than learning in a classroom? There are several advantages in doing so:

  • You can learn at your time, place, and pace
  • You can engage in more reflection, which will enable a better learning experience, more retention, and clearer perspectives
  • Statistics show that classroom based corporate training just does not work

There are several resources (free as well as paid) that will help you in your learning endevours. I will publish links to such learning resources constantly on this blog. Here's one to start with.

Sang Shin facilitates free online Java courses on his Java Passion website. It's really neat.

If you are curious about what informal learning is and why it is better than formal learning, you may also want to check out Jay Cross' blog, and this webpage

Notes: This text was originally posted on my earlier blog at
Here are the comments from the original post

AUTHOR: Ramesh
DATE: 08/21/2006 08:56:54 PM
Nice information. Thanks a ton..Keep it up !!

AUTHOR: Sachin More
DATE: 08/23/2006 04:25:24 PM
No doubt informal learning is anytime better then formal!,

The only thing I felt is you should be very clear what you want to learn, and thats about it.

DATE: 08/23/2006 05:14:08 PM
That was a good observation. In a formal learning scenario you are lead by a coach, it is analogous to being in a school bus, where the route is fixed.
Informal learning on the other hand is like riding a bicycle. You are on your own. This gives tremendous power but also comes with a responsibility to take charge of your learning requirments.
It is very important to first make a plan, then identify resources, and then stick to the plan with discipline, unless there is a good reason to swerve.

AUTHOR: A.K.Purandare
DATE: 06/24/2007 01:11:23 PM
Dear Parag,
Your description brings out the fact that for the learners who are not matured enough(Say in a particular field) class room training may bring satisfaction.while for advanced learner there is no equivalent to on line learning .

DATE: 06/25/2007 05:30:44 AM

For an advanced learner, someone who knows what they are looking for, self motivated and self led learning usually works out best. Online is good because it allows the the learner to connect with resources (information as well as mentors) online. This is a big advantage, since it makes collaboration very simple.

Someone who is not yet as mature, will need more hand holding and guidance, which usually happens best in the classroom ( if at all :-) )

Wednesday, August 16, 2006


Polymorphism is the ability of an object to assume multiple forms. The example below assumes a class hierarchy with Appender as the superclass. For now it is sufficient to know that the Appender class has a responsibility to append a log statement to a certain destination. This class has three subclasses, ConsoleAppender, FileAppender, and DatabaseAppender, each of which implement the 'append' of the superclass to direct the log statement to the console, file, and database respectively. The audio explains polymorphism with this simple example.

[Time: 3 mins 40 secs]

Watch a simple animation of how Polymorphism works.

Note: This post was originally posted on my blog at


Logging frameworks like Log4J allow us to send logs to a multitude of destinations. The code responsible for logging to a destination is usually encapsulated into separate classes.

Without inheritance

With inheritance

When to use inheritance:

  • IS-A relationship
    • An Employee is a Person
    • A BumperSale is a Sale
    • A Square is a Shape
  • IS-LIKE-A relationship

But if the relationship between them is HAS-A (eg: Car has an Engine), then we use composition instead of inheritance.


What is the relationship between the following objects?

  • Bathroom - Bathtub
  • Car - Engine
  • Person - Professor
  • Vehicle - Car

Note: This post was originally posted on my blog at


Encapsulation and information hiding are often used interchangeably. But they are actually different. Information hiding is a design principle, whereas encapsulation is a language facility.
Encapsulation is the process of bundling code and the data it acts on together in one entity. David Parnas describes information hiding as "hiding of critical design decisions", so that the client code does not have to understand the intricacies of the design, and is also oblivious to any changes in design. Encapsulation can happen without information hiding, but will not be effective.
Encapsulation facilitates, but does not guarantee information hiding. Following some simple guidelines will help us create better classes

  • Encapsulation rule 1: Place data and the operations that perform on that data in the same class

  • Encapsulation rule 2: Use responsibility-driven design to determine the grouping of data and operations into classes

  • Information hiding rule 1: Don't expose data items

  • Information hiding rule 2: Don't expose the difference between stored data and derived data

  • Information hiding rule 3: Don't expose a class's internal structure

  • Information hiding rule 4: Don't expose implementation details of a class

  • Read this Javaworld article to better understand these concepts.


    1. Why do we need encapsulation?
    2. Can an OO language exist without encapsulation?

    Note: This post was originally posted on my blog at
    Here are the comments from the old blog post

    AUTHOR: Amol Chaudhari

    Hi Parag,
    The article on javaworld - "Encapsulation is not information Hiding" is very insightful. Thanks a lot for providing us such a good link.
    Prior to reading this article, i never thought of consequences my bad Class design could make. Besides pointing out the subtle differences between encapsulation and information hiding, Paul Rogers has given hints regarding the class organization also, like placing the class variables at the bottom and getters/setters at top makes you focus on the responsibilities of the class rather than the internal data structure. He also hints on the possible choice of method names, like using getPosition() rather using getPositionArray().

    AUTHOR: Parag

    Hi Amol,

    Thanks for the feedback. I am glad you liked the article. Encapsulation is an often misunderstood concept. I especially liked the example of how making an array member private but exposing the fact that the collection is actually an array breaks the concept of information hiding.

    Design decisions do have very real implications. Bad design always accumalates what we call design debt, which has to be paid off at some point of time.

    AUTHOR: Rashmi

    Although we often see the terms 'Encaptulation' and 'Data Hiding' in all OOP articles but often fail to provide a difference between them in terms of a defination.This article was a great help.
    Sir it would be very useful if you could explain the rules for information hiding through a code in java

    AUTHOR: Parag

    Thanks for your suggestion. I will update the post soon with a code example.


    According to Wikipedia - Abstraction is the process of reducing the information content of a concept, typically in order to retain only information which is relevant for a particular purpose. For example, abstracting a premiership football to a ball retains only the information on general ball attributes and behavior. Similarly, abstracting an emotional state to happiness reduces the amount of information conveyed about the emotional state.


    This photograph is attributed to gautamnguitar, and is posted on Flickr with a Creative Commons license.

    Note: This post was originally posted on my blog at

    A quick refresher of object oriented concepts

    In this section we will refresh basic object oriented concepts, to ensure that everyone understands the basics before proceeding.

    Let us start with a brief history of object orientated programming. Object orientation is a step in the evolution of software design

    The purpose of object orientation is to create programs that are flexible, maintainable, and robust.

    Note: This post was originally posted on my blog at

    Tuesday, August 15, 2006

    Designing using object oriented principles

    Welcome to the course on designing using object oriented principles.

    Simula 67 was the first object oriented language, and as it's name suggests was created in 1967. Since then many object oriented languages have been created, all with the purpose of easing software development and making it easier to write robust, maintainable, and flexible programs.

    In this section we will learn the fundamental principles of programming with objects and how to apply those principles while coding in real life situations. Remember, even though object orientation gives us constructs for writing maintainable programs, if we do not use them properly, the resulting code will probably be more unmaintainable than simple structured programs.

    This course covers the following topics:

    A quick refresher of object oriented principles

    In this section we will once again refresh the basic concepts of abstraction, encapsulation, inheritance, and polymorphism.

    Translating requirments into system design

    In this section we will understand how to identify classes and their relationships from a requirment specification.

    Outcome of good design

    This section explains good design and what we hope to achieve with well designed software.

    Design principles

    In this section we will discuss software design principles and best practices such "keep it simple", "do not repeat yourself", "loose coupling", "high cohesion", etc. We will discuss the principles as well as their practical implications. As of now this section covers some basic principles. Other principles like the ''open closed principle', 'Liskov substitution principle', etc, will be added in the next version of this course.

    Case study

    In this section we will unerstand in steps, how to design a software system from a real world software requirment.

    As always I would like to reiterate the importance of reflection and participation in the learning process. As you go ahead, spend a little time reflecting over every section learned, and also participate by asking questions, answering them, and posting your perpectives on the concepts. I hope you find this module informative. Your suggestions are very welcome, please let us know the things we should preserve, and the things we should improve, in the feedback section.

    Note: This post was originally posted on my blog at

    Wednesday, August 09, 2006

    Java certification, anyone?

    I dislike certifications. They usually have a nuisance value more than anything else. But I was pleasantly surprised when I chanced upon Java Black Belt, a developer community based site that offers certification.

    Their focus unlike most other approaches is not theoretical, but geared towards the practice of programming. The questions are created by the community following a moderation and rating process. They do not charge money for the tests, but require volunteer points. Volunteer points can be earned by helping them refine questions, proposing new questions, and even by contributing to open source projects. This goes very well with the philosophy of participation. Volunteers help develop the site, learn in the process, and also get certified. As participants pass tests, they gather knowledge points, and as they gather knowledge points and pass tests, they attain advanced belts, corresponding to their levels of mastery.

    If this seems interesting, and you are already getting curious, then do not waste any more time, go straight to their website.

    Sunday, August 06, 2006

    So you want to be an expert?

    Who doesn't want to be an expert? (Just in case you have stopped here and are pondering whether you want to be an expert... then you have a serious problem buddy. But nothing that the Creating Passionate Users blog cannot resolve).

    Well I will not rant on this topic because Kathy Sierra has said it in such a wonderful way, that I will simply point you to an image from her blog. The image says it all.

    Notes: This text was originally posted on my earlier blog at
    Here are the comments from the original post

    AUTHOR: Tarun Chandel
    DATE: 10/19/2006 10:15:50 AM
    I think there is another important aspect of learning, and that is sharing. An expert if doesn't have ability to share things with others then his/her knowledge is of little use. The ability to share is not easy and not everybody is good at it. But just like anything else in life this can be learnt and improved with time and practice.

    This is my third comment today on your site, you must be thinking this guy has gone crazy but I am very happy to see your blog and you have always been an inspiration.

    AUTHOR: Parag
    DATE: 10/19/2006 12:32:32 PM
    I agree. Sharing is one of the most important things to do with knowledge. It is almost an oligation.

    Most inventions are made on the foundations of thoughts and knowledge that have been shared by great and generous minds.

    Sharing is one of those things... the more you do the more you help others as well as yourself.

    Keep the posts coming. I'm glad you like the site. Thanks.