Why ‘type’ matters?

It matters in OOP if you want to write a framework or develop a OO system that is truly extensible. Good news for new OO  programmers: a) It matters to you if you want to really understand and appreciate polymorphism b) It also helps you to answer the world famous interview question: What is the difference between an abstract class and an interface?

Ignore java interface for now. I mean the java syntax: public interface MyInterface{… (I wonder the optimism exhibited by authors who try to explain interfaces and polymorphism with MyInterface or XInterface).

Every object is of some type: Let me look around. A House is a type of Building. A Chair is a type of Furniture. A Wireless  keyboard is a type of Keyboard. A Keyboard is a type of interface (I mean Peripheral interface..just kidding). A cell phone is a  type of Phone (You just thought of a Phone super-class and CellPhone subclass, didn’t you?).

Type is a way to generalize the properties of one or more objects. For example, you can make and receive calls on any type of  Phone. You can type characters in a text editor using any type of Keyboard. When you check an object instanceof X in Java, you are truely checking if the object is typeof X. If the check returns true,  you can assign the object to a variable of type X (!) and invoke a method defined in X. The object accepts all requests for the  operations defined in X and it’s super types. So, a type essentially indicates a particular interface of an object. An object’s interface defines the set of operations that can be executed on it. OO books refer to the process of invoking an object’s method as ‘sending a  message’ or ‘sending a request’ . You can access/invoke an object only through it’s interface.  An object can be of many types  and many objects can be of same type (polymorphism and substitutability). A client object(caller) doesn’t know anything about an object itself but it’s interface.

If you look at the above paragraph carefully, we have already touched lot of the topics in OOP like Objects, Interfaces, Types,  Interface inheritance, Polymorphism – Dynamic Binding – Substitutability etc. We haven’t talked about the java interface yet. In  fact we haven’t talked about even classes yet. Many people think a class is the starting point of Object-Oriented Programming. Had that been true, it would have been called Class-Oriented Programming.

A class comes into picture only during implmentation of an object. An object’s class defines the template of how it’s object would look like –  by specifying the internal state and operations that could be invoked. How is an object’s class related to its type?

Thinking in Java (Bruce Eckel): Every object has a type. Using the parlance, each object is an instance of a class, in which “class” is synonymous with “type.”  The most important distinguishing characteristic of a class is “What messages can you send to it?”. All objects of a particular type can receive the same messages. An object has an interface. The requests you can make of an object are defined by its interface, and the type is what determines  the interface.

Design patterns (GoF): There’s a close relationship between class and type. Because a class defines the operations an object can perform, it also defines the object’s type. When we say that an object is an instance of a class, we imply that the object supports the interface defined by the class.

Type is important in OOP because that is what allows you to substitute an object with another of same type. The client objects (caller) access the object through the interface defined by its type. For example, a CellPhone and CordlessPhone are different types of Phone that use entirely different technologies. However you could use either of them the same way without having to know about their implementations because they both are of type Phone. You can use a cell phone in place of a cordless phone to make calls and vice versa.

You would be forming a hierarchy of types if you include the interface of one into another. This is known as sub-typing. A wireless keyboard is a type of  keyboard which is in turn a type of peripheral device. In this case, the wireless keyboard includes the interface of Keyboard  which includes the interface of PeripheralDevice type. Remember only the interface (set of operations) is included, not the implementation. That is,  there could be different implementations of PeripheralDevice (mouse, UBS hard-drive etc). Similarly there could be different  implementations of Keyboard (diff brands, standard/internet keyboards, Japanese etc) and wireless keyboard. The wireless keyboard  supports all operations defined by it’s own type + Keyboard type + PeripheralDevice type. This is interface-inheritance with which we inherit only the interface defined by the super type.

Now comes the question of how to define a type in Java. As we have seen earlier, an object’s own class itself defines its type.  When you extend a class from another, that is with class-inheritance, you are actually inheriting both the type and implementation of the super class.  An object of the new class obviously supports the operations defined in its super class . Take the classic  java.lang.Object.toString() method. Every object in Java supports this method because it is a type of java.lang.Object. A button  object can receive mouse events through a listener because it is a type of java.awt.Component. It can be added to a Frame because it is a type of Window which is a type of Container. “abc” is an object which is a type of String so you could invoke length() operation. It is also a type of java.lang.Object so a thread could wait() on it. It is also a type of Comparable so you can  compare it with “def”…Isn’t Comparable a java interface?

Java allows you to define types as pure interfaces (now we are talking about java interfaces). A pure interface defines only the  operations and no implementation. It just defines a type so that any object that implements the interface can be treated the same way. A pure abstract class is exactly same as an interface because it too just forms a type. The difference between an abstract class  and interface makes sense only when the class is partially abstract in which case one or more of its methods are concrete. A subclass in this case inherits the implementation concrete methods defined in the super class. Let’s stop here: When a class implements an interface, you are doing interface-inheritance.  You are making the class of the interface type. When a class extends another class, you are doing both class-inheritance (or implementation inheritance) and interface-inheritance.

You can mix and match these features however you like. For example, if you ever written an applet, you extend from  java.awt.Applet. And, if you want to start a thread (normally a scrolling ticker:) you make your class implement  java.lang.Runnable. In this case, your class has two types: Applet and Runnable. The applet container knows your applet object  through Applet interface whereas the Runnable interface is used in turn by the Thread object you start. Or considering a simple class MyThread class extending Thread, Thread is a type of Runnable and MyThread is a type of Thread. In  the former case we inherit only the interface defined by the type (run() method) whereas in the latter we inherit interfaces of both Thread  and Runnable + implementation of Thread class. Or considering an instance of ArrayList, it is a type of List (as with LinkedList), a type of Collection (as with HashSet), a  type of Serializable (as with String). By extending AbstractList, it inherits the interfaces defined by List and Collection in  addition to lot of functionality (implementation inheritance).

When people say “Program to interface, not implementation”, they mean the interface defined by the object’s type, not an equivalent java interface. You program to an object’s interface as long as your assigned type is a super-type that can potentially have multiple implementations. This allows you to configure or choose respective implementation at runtime.

InputStream is = …;
int data = is.read();

Connection c = …;
Statement s = c.createStatement();

In the first example, we use the interface defined by the abstract class java.io.InputStream. You can use FileInputStream or ByteArrayInputStream or any other types of InputStream the same way. In the second example, we use the interface defined by the java interface java.sql.Connection. You could use OracleConnection or SQLServerConnection or any other types of Connection the same way. This substitutability is a key feature of any OO system.

Let’s check on some common statements made about abstract classes and interfaces.

1. A class can extend only one abstract class whereas it can implement multiple interfaces: This statement doesn’t tell anything about what’s there in the abstract class. People normally mean partially implemented abstract class here in which case, it is both type and class (implementation) inheritance. If it is a pure abstract class, then it is a pure interface inheritance. By implementing multiple interfaces, we make the object of multiple types. Without the notion of type or object’s interface, this statement is unclear.
2. Java doesn’t support multiple-inheritance, hence we have interfaces: Again, by multiple-inheritance, people mean ‘class-inheritance’. However there is no reuse of implementation when you implement an interface. I think it has to read “A java interface is the best candidate to represent a type. In order to design a class that can have many types, we make it implement multiple interfaces”. Example: ArrayList class and Collection and Serializable interfaces.

So, what type are you?

Note: I will try to improve the content of this post after some time. I would like to have a fresh look.

-Raj Radhakrishnan

25000 and 1 Billion

My wife presented me an iPhone 3G as my birthday gift last month. I’m still playing with it to uncover all of it’s features. The multi-touch screen, built-in iPod, 3G Internet, GPS etc do make it a revolutionary phone.  I won’t be surprised if my spell checker skips the word iPhone in the near future. 

However I have to say that I am personally impressed more with the iPhone Apps compared to all the other features. I firmly believe App Store is the place where people spend most of their time. At the time of this writing, there are about 25,000 iPhone applications available and the download count is going to hit a billion. The iPhone website says ‘There’s an app for just about anything’. It’s true.

iPhoneHome

It has not been even 2 years yet since iPhone was released and you already have 25,000 applications. Remember they are just phone applications (the word ‘just’ will soon become inappropriate considering the increasing usage of mobile applications). You need an iMac computer to use the SDK and probably iPhone Developer Program enrolment ($99 for standard program and $299 for enterprise program). People who have been writing these apps range from just-for-fun developers to serious entrepreneurs. Also, my experience with the quality of the applications so far is simply excellent.

Apple’s cut on app price is 30%. More apps + more downloads = more money. From the perspective of iPhone app development, though the primary motivation of  most developers is to make money as well (business opportunity), the ease of development is paramount in keeping the let-me-write-one- app spirit up among developers. I don’t know much details about the SDK/API yet. However if I have to buy a special iPhone  development adapter hardware and configure it, read a 548 page nuts-and-bolts development and troubleshooting guide, off-the-standard syntax and unclear examples, advanced  debugger tools and, confusing configuration and complex packaging in order to write a simple touch-application, I bet we wouldn’t have seen 25,000 number today. Had they got  crappier (poor performance, being erroneous etc), not many people would have downloaded and, we wouldn’t have seen 1 billion number either.

I always believe in things that are Simple, Elegant and Working. Apple just made my belief stronger.

Update: It is 25,000 and 1 billion in just 9 months (not 2 years).

-Raj Radhakrishnan

Design Patterns myths and what people mean…

I have read many jokes titled ‘What people say and what they mean”. I felt I too can come with something on my yesterday’s post “Design Patterns myths you know of..” . Here we go..

What people say and what they mean…

1.What they say – Design patterns are all about some Graphical editor frameworks.
What they mean – I too tried reading the design patterns book and gave up
(As I said earlier, it is really sad. I too wish the book had better examples. I have browsed James Cooper and was disappointed with that too.)

2.What they say – We don’t need design patterns in our project.
What they mean – I know it’s out there; Not sure if we need them really
(It’s not a technology or choice of API to choose between. Patterns are natural parts of an OO system.)

3.What they say – We have to use design patterns in our project.
What they mean – I have started reading design patterns. I want to practice.
(Almost all programmers do this in order to make their resume more attractive (hands-on experience!!). True with other technologies/APIs as well.)

4.What they say – Design patterns are meant only for software frameworks, not applications.
What they mean – I want to stay away as much as possible.
(The flexibility in software is you can always write a working program.)

5.What they say – Come on, we use patterns every day. I just don’t know the names.
What they mean – Please don’t make me read.
(Same as above.)

6.What they say – Singleton is the most important pattern of all.
What they mean – Yes, I can explain the private constructor, static instance and getInstance method.

7.What they say – Classic OO (GoF) and J2EE patterns are same.
What they mean – I can explain Transfer Object (a.k.a Value Object) design pattern.

Design Patterns myths you know of…

1. Design patterns are all about some Graphical editor frameworks  – This is really sad.
2. We don’t need design patterns in our project – One school of thought.
3. We have to use design patterns in our project – Another school of thought.
4. Design patterns are meant only for software frameworks, not applications.
5. Come on, we use patterns every day. I just don’t know the names.
6. Singleton is the most important pattern of all.
7. Classic OO (GoF) and J2EE patterns are same.

-Raj Radhakrishnan

If the following conditions are met…

Conditions:

1. You have a software  application that looks like a comprehensive example of ‘then-current’ technologies and buzzwords (at the time it was developed).
2. It has more than 2 pages of setup instructions. It has more than 2 pages of deployment instructions (excluding external dependencies).
3. You couldn’t set it up on your machine in 1 hour with no or little changes (ok…..2 hours).
4. You couldn’t build/run/test/debug its complete functionality on your local machine (even with mock  services/objects) due to various limitations.
5. The application has configuration information in all possible ASCII forms: properties file, XML, database, environment variables (and some probably custom syntax as well). 
6. It is very much extensible but no one really has extended it. It is very much configurable but the initial configuration never changed. It is very much reusable but it is being used only by its sole instance. 
7. You can’t afford to just scrap your current workspace and set it up again. Your workspace is so stable now and you don’t want to touch it.

 Assumptions:

1. Application size: small to medium
2. Application domain: Anything but rocket science.

Conclusion:

1. Thanks to the developers. They have already created job for some future software engineers.
2. Not only that, they have contributed to #2 and #7 of Lehman’s laws of software evolution.
3. Question: If there was one thing you wished all J2EE developers understood completely, what would it be? Read Rod Johnson’s wish here.
   

I will keep adding more conditions as I find them qualified.

-Raj Radhakrishnan

OO beginner and the Shape example

I hope every OO programmer would have come across the very famous Shape example. They are found in almost all OO books under ‘polymorphism’. Honestly I didn’t get it when I started learning C++/Java many years ago.

There are two reasons why Shape didn’t impress me.

1. Lack of assumption of prior knowledge: The Shapes are normally part of some graphical editor frameworks that are used to build specific applications(CAD, UML editors etc). I wasn’t familiar with any graphical editor frameworks. I had no idea of what shapes and drawing they were talking about.
   
2. Problem with the type of example itself: The problem is two-way:  Without having context of graphical editor frameworks, you can’t understand Shape. Without understanding Shape,  you can’t understand frameworks.

The examples had an abstract Shape and concrete Circle and Square classes with a overridden methods printing “I’m circle” and “I’m square”. The main program would look something like below.

Shape s = new Circle();
s.draw();
s = new Square();
s.draw();

There are many things involved here: Inheritance, Assignability of subclass objects to a super type reference, overriding, abstraction, interface, polymorphism etc.  To a beginner, it is nothing but “we created a Circle, so it printed something; and then we created Square, so it printed something else..what’s the big deal here?”.  Nothing more. The total point is missed entirely. So there is no way one can use this as a classic example.

To add more confusion, they show the assignment of Circle immediately followed by Square. In real world, these different objects are never created one after the other in a sequence. In fact most of the times you don’t even know how they are created.

I think the beginner example should be taught using some real-world but simple objects. It should use a real-world object and interface. It should explain by itself the relationship between an object and it’s interface. Let me try something new.

Stop..!! Don’t rush to see the  java code.  And, don’t just stop with the example.

Consider an electrical swith. It is an interface used to control the electrical appliances we have at home. The switch doesn’t give you a clue about the connected device but you can’t operate the device without using the switch. A switch has two operations: on and off. All the electrical devices are accessed using the same switch interface but they implement the operations differently. When you switch it on, you might see your room getting filled with light or cold air or music, depending on whether you have connected a lamp or fan or a music player to the switch (Don’t go too deep arguing what is the electrical socket and plug etc..:-) ).

public interface Switch{
   public void on();
   public void off();
}

We want to implement Lamp and Fan. They implement Switch interface because that’s the only way to operate them.

public class Lamp implements Switch{
   public void on(){
      System.out.println(“Bright”);
}
   public void off(){
      System.out.println(“Dark”);
   }
}

public class Fan implements Switch{
   public void on(){
      System.out.println(“Run”);
   }
   public void off(){
      System.out.println(“Stop”);
   }
}

1. Switch s = ……………..;//we get the object somehow
2. s.on();
3. …
4. …
5. s.off();

I have intentionally left the RHS of line# 1  blank to illustrate that We don’t know the assigned object and we don’t care. The line numbers 1 to 5 don’t have any knowledge about the actual object that is being pointed to by the variable ‘s’. We don’t have to know if the assigned object is a Lamp or Fan as long as we can use the Switch interface to switch it on or off. This is the key to understanding runtime polymorphism.

The above example also illustrates one more important thing: Separation of  interface and implementation. The calling code (line 1-5)  uses only the Switch interface without a static binding to any particular object type (That ‘blank’ code could invoke some other method that reads from a configuration file whether to instantiate a Lamp or Fan etc – Creational Design Patterns).  This is what allows substitutability of objects. This is what we strive to achieve with polymorphism, not just printing different things.

You may have noticed that Shape is normally an abstract class in the examples whereas I have used Switch as an interface. Ignore Switch.java, Lamp.java and Fan.java. Look at the following code snippets that could use ‘Switch’ in various contexts:

• Switch s;  (or)
• public void operate(Switch s){…}  (or)
• public Switch getControl(){…}

You cannot tell whether ‘Switch’ is a concrete class or abstract class or an interface. All my above explaination still holds true except different coding constructs. This is the key to understanding interfaces. I will write about it in detail in the near future.

Now it’s time to take a look at some real-world Java/J2EE.

Servlet Container:

String servletClassName = readFromWebXML();
Class servletClass = Class.forName(servletClassName);
Servlet s = servletClass.newInstance();
s.init(..);
…
s.service(…);
…
s.destroy();
…

 If you have programmed a Servlet,  this example should make more sense to you from the Servlet Container perspective. It’s nothing but a framework. It doesn’t know which class you have written or what you have written within it’s service() method. All it does is to load the class, instantiate and invoke the methods appropriately.

To understand these concepts and examples, you should perceive from two opposite angles: The interface side (caller) and the implementation side (callee). You should think of these two things being developed by two different sets of people (like Switches and Lamps are manufactured by two different companies. Or Universal remote controls are manufactured by Logitech whereas Sony makes TV, DVD player and home theater systems).  Tomcat,  Weblogic and Websphere all write the servlet containers and we write the Servlets. They write EJB Containers and we write EJBs. They write JMS implementations and we write Message Listeners. And finally, open source community writes Eclipse framework (Shape) and IBM Rational Software Modeler team writes ClassShape or InterfaceShape or SolidArrowShape or DottedArrowShape that would override a paint() method. I still don’t know it exactly!!.

-Raj Radhakrishnan

 

 

 

The Migration – OOP(s!!!:))??

I have discussed this with Manoj Waikar a while ago. Co-incidentally, when I was talking to my another best friend Sakthivel Srinivasapuram last night, he too mentioned of it. So I thought of sharing my personal experience.

I have programmed in C and have good knowledge about C++.  However my jump into Java was almost immediate after I started programming. So, I didn’t get much of the procedural influence.

It’s generally tough for anyone to learn a OO language.  The reasons being the plentiful advanced concepts they OO world possesses. Moreover, it is more difficult for someone who has prior experience in a procedural language like ‘C’ as compared to someone who has no software development experience at all. The default approach would be to master Java language syntax followed by some kind of one-to-one mapping:  a .java file for a .c file; a method for each ‘C’ function. They visualize a java file to be a placeholder for a group of functions. They tend to write static methods (that work on incoming data) rather than instance methods that work on the instance’ own data (common symptom). It’s because they try to map the concepts from ‘C’ into Java. This is generally known as “Writing C programs in Java syntax”.

And, it is true with migrating from C++ to Java since there are some differences in terms of syntax and practices. For example, in C++ you would use a base class pointer to reference a subclass object to realize polymorphism whereas in Java you could simply use a reference of any super type(super class or interface). It’s okay as long as such style is minor or negligible within a Java/J2EE project. However such things could cause a major impact when things start mixing up.

Consider the following pluggable authentication code:

Note: If you don’t get it first time, it’s okay.

public abstract class LoginValidator {

public void login(String userId, String password) throws AuthenticationException;

public static void checkLogin(LoginValidator clientAdapter, String userName, String password) throws AuthenticationException{

…

clientAdapter.authenticate(userId,password);

…

}

}

Someone writes a client adapter class that would extend this class, implement the login() method to communicate with it’s environment specific authentication servers (iPlanet, DB etc). For example,

public class XYZCorpLoginValidator extends LoginValidator{

public void login(String userId, String password) throws AuthenticationException{

//code to call iPlanet or DB server to authenticate

}

}

The login framework reads the client adapter class name from a property file, instantiate it and call the static LoginValidator.checkLogin() method passing the instance.

LoginValidator clientAdapter = (LoginValidator) createInstance(clientAdapterClassName);

LoginValidator.checkLogin(clientAdapter , userId,pw);

If you find it confusing, good. You are with me. Let’s see how this could have happened. Basically, the programmer (most likely with C/C++) wanted to define an interface, hence he/she started with an abstract class (Class inheritance vs. Type inheritance). For no reason, he/she wanted NOT to call to login() method from within the last snippet above. Then he felt to keep both the interface and the invocation together, hence he wrote checkLogin() method. For convenience, he just added ‘static’ to call it like a procedure/function (‘util’ method?).

There are too many problems here. By looking at the LoginValidator class, you never understand how it works from both framework and client perspective. It messes the interface up (I mean the concept of interface, not the java construct ‘public interface’; I will write about it later).  The method static method is just too much of round-trip. Being an abstract class, it enforces the client not to have any other parent. And, to top it off, some people would include singleton code (not included here).

LoginValidator should have been a java interface with login() method in the first place. This addresses all the issues. XYZCorpLoginValidator would simply implement it. The product’s login framework should instantiate this class, assign it to LoginValidator reference and call login(). It’s as simple as that.

I proposed the above solution to keep the contracts minimal and promote maintainability. I couldn’t succeed. 

-Raj Radhakrishnan

What I like about the 3 lines Java XML parsing?

It requires only 3 lines of code to parse an XML file in Java.

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder b = factory.newDocumentBuilder();
Document d = b.parse(new FileInputStream(“Order.xml”));

That’s it.

The very interesting thing about these 3 lines is, they exhibit all the Creational Patterns upfront.

1. DocumentBuilderFactory depicts Abstract Factory, Singleton and Factory Method patterns.
   • Abstract Factory: DocumentBuilderFactory is an Abstract Factory interface. The concrete classes of the same are provided by various parser implementations (Sun, Xerces, Castor etc) Example: “org.apache.xerces.jaxp.DocumentBuilderFactoryImpl”. An object of this class is returned by the newInstance() method.
   • Singleton: A pattern almost every OO developer is familiar with. The static newInstance() method returns the singleton object of Abstract Factory implementation class. This also depicts the Singleton-Subclassing and Singleton-Registry which I will write about later.
   • Factory Method: The method newDocumentBuilder() is a Factory Method. This method is implemented by Abstract Factory implementation classes that return a concrete DocumentBuilder instance. Example: “org.apache.xerces.jaxp.DocumentBuilderImpl”. (In design patterns jargon, this is called as a “Product”). All the other createXXX() methods on the Document (createElement, createAttribute etc) are Factory Methods too. Probably these factory methods return clones of already created Element or Attribute objects which is nothing but Prototype pattern.
2. Builder: DocumentBuilder.parse() method follows Builder pattern. It parses the XML file and constructs the DOM tree.

One last word. It’s “Factory Method” pattern, not “Factory”. I think people consider Abstract Factory and Factory Method patterns as one single pattern though the former is normally implemented using the latter.

-Raj Radhakrishnan

The Ever-living Software Complexity and Flexibility

You fixed a defect yesterday or found a new one, or insisted more testing, or proposed a re-design for an existing application or debating the best framework for a new application. You know that you have been doing the same thing all along your career and there is no change in the cycle. This repetition is common across all projects regardless of the methodologies, programming languages or technologies. You also know that you as a software developer, will continue to do the same in the future as well.   Why can’t we just write applications and forget them? And, move on to the next application? Why does every piece of software we write need maintenance and that is so expensive? Though nobody knows the answers, I think we know the problem: Inherent Complexity of Software.

The problems described above can be fit into at least one of the following (Object-oriented analysis & design with Applications by Grady Booch: Chapter 1 -“Complexity” ) :

1. Complexity of the problem domain
2. Difficulty of managing the development process
3. Flexibility possible through software
4. Problems of characterizing the behavior of discrete systems.

Although we strive to improve upon dealing with #1, 2 and 4, I don’t think there is anything we can do about #3. “Flexibility” is a very wide term and it offers both good and bad to software development. For example, if you ask 5 developers to write a program that reverses List elements, the only commonality will be that all 5 programs would compile and run. There are always multiple solutions: from a simple-working to best-performant or building from the smallest possible element to reusing existing code etc.  The solutions vary with context of the problem, time-to-deliver and, knowledge and experience of the programmer (development flexibility). Not many people care about the quality of the solutions as long as they work and can make the system running. However, how good the solutions are, will be proved only over time. A bad code becomes a mystery very quickly and everyone would like to stay away from changing it and everyone tends to develop minimal-touch solutions around the existing problems (believing a possible reason for the way the code has been written  – the fear of breaking), eventually making it more complex.  Again it is acceptable in software because they still work (maintenance flexibility).

My friend Partha Roy Choudhury often refers to a quote: “It’s very easy to write software that a computer can understand (that doesn’t necessarily make it a good program)”. My tennis coach often says: “The easiest thing in Tennis is to put the ball on the other side (that doesn’t make you a Pro).” I don’t find much difference between the two!!

-Raj Radhakrishnan