Java: What's up with "Impl" in Class Names?

What to name it?

This is a constant question we are faced with in daily life. We want to come up with perfect names for our babies. We want to name our animals (pets) and they seem to be happy to have a name! And it seems to be a big thing! Otherwise we wouldn't have naming ceremonies like these. We try to name (rename) our buildings (otherwise what would  you call Empire State Building?), streets, cities and countries. (Myanmar or Mumbai is yesterday's story. Mexico wants to rename themselves as Mexico! See here.) And naming is not an easy thing to do. A world recognized music composer in India, Illayaraja, called his symphonic music album "How to Name it" for lack of a better name.

What's that got to do with this?

Java developers (or any developer for that matter) are merely imitating the real world and they too have to face such challenges while naming their programs, classes and objects. We don't want to name (can't) two entities same name. That would cause confusion (Name Collision). To avoid this, we use packages, name spaces, domain etc.

Each "object" tends to have 2 forms in Java world (or .Net, C++ etc) - the class and it's interface! An interface is a class's "public profile" - much like public profile we have in linked-in, what we want other classes to know about this class.

We could say the interface is not unlike a business card or a cover letter we send with our resume when we apply for a job. Cover letter contains exact amount of information that may be of interest to the other party while the resume may have lot more inner details. Now they both are about you, but not the same.

So, what's up with "Impl"?

So, if you are a developer, what would you call the interface and implementation for an object that models a real car?

[caption id="" align="alignright" width="356"] OO interface names[/caption]

This is not as simple as it seems. There are at least 2 camps. One camp, the Microsoft based camp calls the (implementation) classes by just the name and prefixes their interfaces with "I". To them the Implementation is the real object and interface is it's business card. The other camp (seemingly started by IBM) uses the plain name for interfaces and the (implementation) classes are named with a suffix "Impl" for Implementation. Here the interface represents the abstracted real word object and the Implementation class merely has extra (inner) details that doesn't concern outsiders (other classes). The Java world mostly follows the "Impl" convention.

So there you have it, when you see Java classes named with "Impl" at the end, you know why. End of story, right? No, not really. Object Oriented pundits and purists don't agree. Here is a nice post where the author diisagrees with "Impl" usage. And here is another perspective to it. And it's an ongoing debate. Don't believe me? See here, here, here.

So which way to go?

Naming your class can be a personal choice, but most of us write programs that will be shared with others in the community. That's why conventions and best practices exist. If you are working on a project, set up and follow standards appropriate to your shop.

In some cases, you may not be able to change the "I" or "Impl" in names. Many programs may have some type of interface (protocol) like CORBA, COM, Web Services. In these cases, they generate code (Stubs, Skeletons etc) that you have to based your own code on. Document these and stick to those conventions to avoid any surprises.

Personally, I am OK with using Impl suffix. I work with EAServer which runs both Powerbuilder and Java objects. These objects "talk" to each other using CORBA IIOP. Both Powerbuilder and EAServer tools generate CORBA IDL files which in turn are used to generate stubs and skeletons in Java (or C++). Developers then write Implementation classes for the interfaces generated. The class files generated and the impl classes may end up in the same Classpath and to avoid Name Collision, we have to name implementation classes differently and the convention is to use Impl suffix. This is a convention I am sticking with in my current project.

Reference Links

A note about my "cheesy" cartoon there. While searching for something relevant I found Toondoo where you can make your own cartoon. You can start with a free account. I also use openclipart for some of the pictures in my other posts.

http://www.toondoo.com

http://openclipart.org

http://isagoksu.com/2009/development/java/naming-the-java-implementation-classes/

http://docs.oracle.com/cd/E13183_01/en/alui/devdoc/docs6x/aluidevguide/ref_idk_deploymentimplkeys.html

http://leshazlewood.com/2009/03/03/java-class-naming-conventions/

http://www.gnu.org/software/libc/manual/html_node/Interface-Naming.html

http://osherove.com/blog/2006/6/14/interface-naming-anything-but-javas-standard-please.html

Object Oriented Concepts - An Introduction

Work has been busy for a while. I am finally returning to my blog on PB.
We started looking at PB program as a collection of Objects in the last post. Yes, PB is now an object oriented language, but it sure did not start that way. Sure it has some objects like windows, buttons etc, but does that make it an Object oriented environment automatically? This topic itself is so huge, So, I decided to touch on these first before continuing further with PB.

What  is an Object?

The simplest definition of an object is a thing, a noun or an entity. In the programming world, this has come to mean a self contained programming unit. By hooking different "objects" you can make a program. Objects themselves are not new. Remember the old C programs? When you compile individual C files in a program, they were converted to "object" file. Though it doesn't mean the same, it stands for a program unit. By linking different "object" files, we arrived at the final program (Executable). Then there were modules. Even though there is a subtle difference between a module and an object, in theory they are the building blocks of a program. Remember, COM (Microsoft .Net evolved out of this eventually)? The idea was to have bunch of OLE (eventually called Active-X) that would be glued together in a program. In fact, Visual Basic was invented for such a purpose originally. We will explore more about objects in the coming posts. But, while you are at it, think about another term frequently used in OO: a Class. Several authors allude this to a blueprint, cookie cutter, a mold for creating objects.

What is Object Orientation (OO)?
An object has several other characteristics that makes an object in an Object-oriented language different from earlier definitions of objects. If you Google for the word “Object oriented”, you will find a million links. If you sift through all those, you will come to the following conclusion:
Object Oriented is a new paradigm (though it's been around for 30+ years now) and it is difficult to learn and/or master. Yet you see, every programming language (PHP, Coldfusion, PERL, PYTHON, you name it) out there is joining the OO way. So, if you are going this route, you have to get the concepts right.

Object oriented is many different things to many different people. Even the languages that claim to support OO now, are not fully OO themselves. So, let us discuss fundamental definition of being object oriented. In later posts, we will continue to drill down this topic.
Several books talk about Object Oriented (OO) approach to contain the following four basic characteristics

• Abstraction


• Encapsulation


• Inheritance


• Polymorphism

We will analyze each of these below.

Abstraction
Almost anything we do with computer software is an abstraction of the real world. An ATM machine is essentially modeled after a real-life teller it came to replace. Abstraction itself is not OO. Cobol and Fortran programs abstracted business models and mathematical models respectively for about 50 years now. But the abstraction in OO, is much closer to the real life. After all, real life is full of objects: people, earth, machines, food, microwaves, books, TV, radio etc.

In OO, we try to call a Radio a radio and define it's properties and operations to emulate real life one (actually a radioObject is more appropriate name for it; of course, it's a software object not a real one, but you could make it to play music!). A software abstraction is context based. For e.g., when we abstract customers, shop owners and employers we are abstracting people. In such an abstraction, we definitely would like to know their names, but we don't need know their race, gender, height, weight etc. Where as, if the person abstracted is a patient, suddenly some of these characteristics matter!

A speedometer in a car is a good example for abstraction. We see the needle to get an idea as to how “fast” or slow the car is going. Abstraction in this case varies between MPH in the US to Kilometers in some other countries. A thermometer, similarly abstracts how "hot" outside temperature is.

Encapsulation
This is the next characteristic of an OO programming environment. Encapsulation, simply means hiding private data and showing proper (public) interface. We don't want to see inner-workings of a microwave or a car when we are using it to heat our pizza or driving to get one. When we shop for a car, we are happy if we find a steering wheel, something that looks like gear, brakes and of course, those 4 wheels that the car needs to “run”. Of course, some of us would like little more glossy finish, but none of these involve putting engines right next to you on the front seat! And of course, the way those engines come pretty well sealed these days, they are very well encapsulated themselves. There is one “interface” you see, the oil cap that lets you fill oil. The content, level of oil, is not immediately visible. If you open and use a dip stick, you can find out the actual level of oil!

Speedometer mentioned above is also a good example of encapsulation. To “see” speed one doesn't need to look at rotating gears, tires, road etc. They just look at the interface called “Speedometer”.

Encapsulation itself is not a new concept. It's been around since the early days of programming. In Pascal, you could achieve certain amount of encapsulation by proper function design. C of course, offered modular programming (file level – see post “Modular progamming in C” for more information).

Inheritance

The most common meaning for this English word is the property (read “Wealth”) inherited from ancestors when they pass on. And it's not just property that can be inherited. We also talk about some characteristics passed on (genetically). It's this latter mean that's adapted in the computer lingo. Inheritance in OO allows an object to acquire properties and behavior of some other. So, we talk of a Dog object inheriting properties of an animal object (actually class, we will discuss these shortly).

Of course, in real life we don't say Dog inherited from Animal. We say, Dog “Is A” animal. We also say Car “has a” engine. And we have access (reference) to computers in the hotel. These are different types of object relationships in OO. An “Is A” is considered to be inheritance. A “Has A” relationship is called composition. And a reference to an object out there, is an Association.

Of these, Composition and Association were possible is non-OO languages as well. Inheritance itself could be indirectly implemented through these 2. For e.g., in C, using plain structures and function pointers we could mimic any of the above relationships.

Polymorphism

This came from a Greek word. Poly means many, morph – form. For e.g., different forms of shapes. Circle, Square, Rectangle and Triangle are all shapes. Of these, Rectangle and Square are similar, in that they both have sides. Circles and Ovals could be similar.

Now, shape is a noun, an object. How about a verb – an action or behavior? Let's take the word “Play”. Try using this English word in sentences and you will see how many different objects can play in how many different ways. Like playing a piano, like playing Football, Playing cards, playing a part in a play, Play with a child, Playing with life! This is truly a polymorphic word. How about the word, “Talk”? “Talk” to a dog, barks, cat meows and the cow moos, not exactly talk in the human sense, but in the sense of “open your mouth and make a sound” it's the same operation, with various forms!

In this post, we tried to explain what OO is and try to understand the terminologies typically related to the OO. This wasn't totally a technical discussion. Now that we got some definitions out of the way, let's get down to business with the topic of Object Oriented. Try to remember some of the examples when we get to our next post.

Below picture summarizes all these terminology as they relate to a Microwave.