Why isn't Java's Object class abstract?

This is the question which Ajiit Balan asked me a couple of days ago. As I told him, I have a answer, but I'm not sure if it's correct or complete - hence this blog post. If you have any points to add, please feel free to do so in the comments. But first, Ajit's question in full:

In Java the Object class is a concrete class. Now my question is why did the designers of the Java API make the Object class a concrete class.

According to the GOF design principles one must always program for interfaces and not implementation. The designers of the Java API could have used abstraction here which is one of the OO principles.

If everything in Java is an Object implicitly then why is the Object class a concrete class? It could have be an abstract class with common methods sitting in the Object class. It could have also been designed as a skeleton class where it implemented an Object interface and provided a skeletal implementation in an abstract class called AbstractObject similar to the way the Collection classes have been designed.

Here's my 2 paise:

Creating useful abstractions is good - however, this should not be confused with abstract classes. Similarly, programming to interfaces does not literally mean using the 'interface' keyword in Java. In fact, one can still do all this in languages like Ruby or Javascript where there are no 'abstract' or 'interface' keywords. In the case of Javascript, there isn't even a 'class' keyword, yet everything is still an object. The GoF patterns book provide solutions to specific problems, some of them created by the language itself. For example, you don't need the strategy pattern in Ruby or Javascript - you'd use a block. As Neal Ford explains, nomenclature is good, recipes - not so much.
To clarify, creating layers of abstraction helps you simplify the root problem you are trying to solve - the classic example being high level language vs. machine language. Programming to an interface is essentially defining a contract which your code will adhere to. A contrived example would be 'provided a motherboard supports PS/2, I can connect any mouse with a PS/2 interface to it.' The motherboard doesn't care whether the mouse uses a ball or a laser. Indeed, you're free to change it at any point, because the motherboard isn't aware of the implementation details. All it knows is the interface.

When deciding whether to make a base class abstract or not, I have a simple rule of thumb. I ask myself, 'Is there something I need to force child classes to do in a manner which I can't predict?'. Well, actually that's the second question. The first question is, 'What's changing and can I encapsulate it?' - some standard patterns which help answer this question are the strategy, visitor and command patterns. More often than not you shouldn't need an abstract base class. Favour composition over inheritance and all that...

But back to the second question. What is it that Object says every derivative class must do? In Java, these are described by methods like equals(), hashCode(), getClass(), toString() etc. Now which of these methods can the Object base class not provide a default implementation for? None of them - they can all be given default implementations very easily. Therefore there is no case for an abstract class.

Indeed, the 'is-a' (inheritance) relationship which Java objects have with the Object class is not the only way it's done. In Javascript, a similar result is achieved purely through 'has-a' relationships, in other words, by composition. Every object has a 'parent' object accessed through the prototype field. That object in turn has another parent object. Eventually the chain terminates with the base Object (remember, there is no distinction between objects and classes in javascript). Any attempt to access a field or method (again there is no distinction) will propagate up this prototype chain until either the field is found or the chain terminates at the base Object. Javascript has no inheritance at all, everything is done through composition.

The last part of your question is about using an Object interface and an AbstractObject. In the context of all that I have already said, the answer is 'We get nothing extra from creating an interface and an abstract implementation. So why bother?' or in short, YAGNI.

Non-rails unit tests don't hit the db but Rails unit tests do

Generally when unit testing in non-Rails apps, we never write unit tests which hit a database. If we're forced to, we keep them to a minimum, treat them as a symptom of bad design and do our best to refactor them away over time. This is because you should be able to create and use models independently of your database - otherwise your code is implicitly tied to your db schema, something you want to avoid.

Thing is, this isn't true for Rails because of the neat one-to-one mapping of a table to a domain object.

Just an observation.

The best of the worst: Standard patterns of horrible code from Java and .Net

There are some standard worst practices in code which make my teeth ache when I see them. They can appear at any time in a code base and look very innocent but will turn everything around them into spaghetti in short order. Someone somewhere near you is typing out one of these insidious bits of code as you read this. You have been warned.
I've already written about the one where people create namespaces and constants to handle types. Something like

public interface CarType{
 public static final String AUDI = "audi";
 public static final String MARUTI = "maruti";
}

The constants are usually ints, or even worse, Strings. The latter start popping up everywhere, including (in one bad case) eventually showing up as a piece of text on a UI. But enough of that, let's move on to today's rant.

Today, recruitment had bribed some of us developers into a code review session (our interview process requires candidates to submit code) over lunch by ordering from Subway. Some of the code I reviewed brought back two of the most annoying, yet widespread development worst practices. Here they are, one from Java and the other from .Net

.Net: Everything is a DataSet
Aargh. Why of why is there this obsession with mapping everything to the rows and columns of a DataSet? Everything is not a DataSet. They're People and Employees and Magnolias. I've seen code where there wasn't a single developer created class! And this from people with several years of experience, not freshers. The flow inevitably looks something like Create DataSet -> Read from xml file/webservice -> Optionally pipe it around a bit using a few web services -> Pump into DataSet -> Perform operations, creating and manipulating DataTables, DataColumns and DataRows by the dozen with no classes and tons of procedural logic -> Bind these to UI objects. If you're really unlucky, that 'tons of procedural code' I mentioned will be in a class which inherits from Form. A more thorough, consistent and violent violation of OO principles I am yet to come across.

I would suggest that XStream .Net and NHibernate be used instead to achieve the convenience that DataSets offer in the short term, but over a longer period and while maintaining code quality.

Java: Every field must have a getter and a setter
That strange and wonderful idea, the bean, has made a whole generation of Java developers completely inured to the idea of maintaining encapsulation. The bean was created to solve a specific category of problem, but the structure of the bean has spread like a virus, destroying the integrity of the most innocent of domain objects. When doctors wish to test the reflexes of such developers, the preferred method is no longer a mallet applied smartly just below the kneecap. No, you need just give them a class in an editor, ask them to add a field and check if they automatically add a getter and a setter for it.
The only time using a setter is acceptable is

• if the state of the class cannot be corrupted by using it (calling setText on a TextBox can change its state, but does not corrupt it)
• if the framework demands it

Getters aren't as bad as setters, but over time on a large code base they encourage the processing of data outside of the class to which it belongs. From there, it's a short and slippery slope to code duplication and other evils. In combination, getters and setters can reduce once healthy domain objects to pale DTOs.

I would suggest simply avoiding setters unless a change of state for that field does not corrupt the object. A lot of frameworks now understand this and help developers do away with setters. Hibernate, for example, allows you to configure field level access (Hibernate will populate your domain object fields directly using reflection, even if they are private), thus removing the need for setters.
For getters, use them only when the data read using the getter will never be processed - in other words, only in situations like binding to a UI or persisting to a database.

Bringing business logic to the browser, or why you should develop in JavaScript

A few weeks ago, I'd observed an interesting side-effect of building an AJAX web application - that the content served asynchronously would not be available to search engines. I'd written a post about it, trying to express the idea that there may be a way of categorising web applications based on whether the content served is the kind that it is valuable to index for search (Wikipedia, Amazon) or where it simply doesn't make sense (Google docs, the vast majority of enterprise web applications). Unfortunately, I made two mistakes. One was that I used the terms 'web site' and 'web application' to distinguish between the two - these terms already mean a lot of things to a lot of people - and second, the idea was raw and my articulation poor.

However, that idea has stayed with me and I've been thinking about it a fair bit since that last post and I've come to the conclusion that what I'd made the focus of my post was merely a side-effect of other, larger trends we're seeing around web frameworks, the relevance of HTML and the way we do web development in general. Please bear with me while I put these ideas down and feel free to flame me to your heart's content in the comments section :-). I'm looking forward to the feedback on this.

First off, I want to get rid of the language baggage for the purposes of this post. I'm going to christen the two types of web applications I have in mind as the web based Information Publisher application and the web based State Interaction application.

An Information Publishing application is a web application whose primary focus is to serve content. The content can be video, audio, text, whatever, but the job of the application is to just serve content. A classic example would be something like Wikipedia or Google search. In both cases, there is information which needs to be served to an audience for consumption. The fact that content in Wikipedia is fairly static while that in Google search is highly dynamic doesn't change the fact that they still essentially publish information.

Contrast this with the web based State Interaction application where the objective of the application is to allow the users to interact with various entities and affect their state (again, Google docs and most enterprise applications). You may publish information as the end product (generate reports, say), but this is not to be confused with the act of creating that information by allowing user interactions with various entities.

The interesting thing is that many web applications have both types and you see one or the other depending on what you're doing with them. Any decent wiki is a good example - when you're in 'edit' mode, it's a State Interaction application (a developer would immediately see entities like Page, Content, History etc.) and when you are viewing wiki content, it's an Information Publisher. The authentication functionality that many websites display is again an example of a State Interaction built into what is otherwise an Information Publisher.

Now, let me explain why I think this distinction is important.
The common underlying infrastructure available to both types of applications is the web browser, with rendering through HTML and communication with the server through gets, posts or AJAX.

In the case of an Information Publisher, this infrastructure is ideally suited to the task. HTML was, after all intended for precisely such uses. Communication with the server to request certain kinds of information can be handled easily and elegantly using name-value pairs (parameters) in a get or post request. A Google search request for the word 'hello' looks like this: http://www.google.co.in/search?q=hello. Nice.
State Interaction applications on the other hand usually have a whole bunch of entities which the user needs to interact with and which usually also need to interact with each other. These live on the server and their interaction with the user is through a user interface rendered using HTML. Changes to the state of an entity or object happen, again, by sending name-value pairs or a json string containing data to the server where these are parsed and some action is taken to alter the states of various objects. To put it bluntly, you have a bunch of objects which demand a high degree of interactivity and we get our UI to talk to them by passing strings around! Not so nice.

The fact that this pain has been felt by developers can be seen in the evolution of web development over time. A bunch of frameworks and tools have been created which build abstractions over this infrastructure to make State Interaction application development easier. For example, ASP.Net 1.1 tried to bring in abstractions which mimicked those used in WinForms. However, attaching an event trigger to a check box (something we do routinely in thick clients) would result in a page reload every time that box was checked or un-checked. The abstraction was defeated by the limitations of infrastructure used (posts). You could develop the same way as you did in WinForms, but the results were far from satisfactory. Things like this made it obvious that while we did need an abstraction, it couldn't really mimic the desktop world where the UI and the model are a method call (or ten :-)) apart. Sure, you're still using a MVC, but very differently from how you would in a thick client. And a whole lot of web frameworks like Spring and Rails have sprung up to support this abstraction. However, these still failed to address the fundamental problem - that highly interactive UI's cannot effectively communicate with their models (data binding, anyone?) by passing strings around.

Why is it that people say thick clients are more interactive than web clients? That this is true is not in doubt, or we wouldn't have such a hullabaloo about AJAX and the responsiveness it introduces. Often, this lack of responsiveness is blamed on the rendering engine of the browser, which renders content using HTML. Obviously, you're told, a markup language cannot be as flexible and easy to develop UI elements in as is a thick client rendering environment using abstractions like Panels, MenusBars and what have you. But this is no longer true since the entire HTML DOM is available for us to manipulate using javascript and the DOM tree structure is remarkably similar to the tree structure of nested widgets in a thick client, something the GWT has used to build up an excellent abstraction - but more on that later in the post.

Therefore, I concluded that this lack of responsiveness has less to do with the rendering medium and is mostly because the communication pipe between the UI and its backing model in a web application is far less effective that that in a thick client.
Which of course begs the question, 'Why have we been so poor in bringing the model from to server the browser?' The obvious answer is performance. Until recently (in fact I'll go so far as to say until the release of Firefox 2) the performance of javascript was so poor as to prevent its utilisation for anything more than a handful of field validations. Creating more than a couple of dozen or so DropAreas on a page using Scriptaculous would make dragging anything so slow that it was next to unusable. But javascript performance has increased in leaps and bounds and it is now possible to actually develop full fledged MVC architectures running purely on the browser, much like a thick client. AJAX is used purely to sync the model on the client with the model on the server, exactly like you would in a thick client. One of the earliest abstractions developed to support this model of State Interaction application design was the GWT. People have shied away from developing applications purely in javascript for many reasons, but the GWT eliminated most of them in one fell swoop. However, there is a general awareness now that developing within a disciplined framework makes life a lot easier (a lesson learned from Rails) and we're seeing javascript MVC frameworks like Jamal and TrimPath surface which are trying to build on this experience to make disciplined development in javascript easier. We've seen pure javascript client applications before in websites like Netvibes, a feed reader with a thick client feel and bunch of desktop UI entities like windows, titlebars and tabs which has been around since 2005. However, it's only now that we're seeing this style of development starting to move into the mainstream.

Of course, these abstractions still stuffer from limitations imposed by the underlying infrastructure. For one, javascript doesn't support threading, so data binding in a GWT application should be handled delicately or you could end up with annoying screen freezes. But all things said and done, these applications are still far more responsive than traditional web applications where the model sits only on the server. As importantly, they are far easier to develop since as I said before, server calls are purely for model syncing and your view objects can talk to model objects using method calls.

Having said that, client side models are a fairly bad idea for a Information Publisher for the simple reason that they're quite unnecessary. The challenge, in my opinion, is to clearly identify which portions of a website require State Interactions and which are good old Information Publishers and implement them accordingly using the appropriate technologies. I'd gotten quite gung-ho about GWT and went and developed an Information Publisher type website using it, only to realise later that none of the content was available through a Google search (I did however fix that issue, but it was a hack which won't scale). You can imagine where this could be crucially important to some websites, especially those which sell products or services. AJAX and dynamic rendering are pretty cool, but should be used appropriately.

To summarise, when developing a web application, it is important to identify which parts of it are information publishers and which are state interactions. As the complexity of the state interactions increases, one should seriously consider bringing the model from the server to the client and using AJAX just to keep the model data in sync. Tools like the GWT, Jamal and TrimPath not only make this possible, but also supply a whole lot of infrastructure (like unit testing and debugging in the GWT, scaffolding in TrimPath) to make the developer's life easier when developing in javascript.

Update: 2007/06/27
I'd originally titled this article 'Why things like the GWT and Jamal are going to help keep web developers sane' but changed it because it was rather vague.

You may also want to read: When should you choose Google's GWT for your web app?

The difference between a web application and a website

Something worth considering in this era of powerful, interactive - alright, let me grit my teeth and say the buzzword - Web 2.0 websites, is where the line is drawn between a website and a web application. Why am I bringing this up? Read on.

I'd been building this website about a month ago. This is a simple site, no rocket science, just a bit of content that needed to be made available on the net. After a fairly frustrating time trying to achieve the desired effect using CSS (I'm no expert :-)) I gave up and decided to use tables.
Once I'd made that decision, it seemed logical to me to just develop in GWT and be done with it, since I wanted to have a bunch of divs and manipulate them with javascript. I could then layout the lot using GWT's VerticalPanels and HorizontalPanels which translate to tables anyway. All the content would be rendered dynamically, but I saw no problem with that.
To cut a long story short, I got the site done and put it up, replacing an older one which we weren't too happy with - until a few days later we realised that a Google search for 'Activ Mobs' produced nothing from the site except the link. Obviously (hindsight is always 20/20) Google is not going to execute all that javascript to produce the content and then index it.
Which brings me to my point (finally!) - if you've got a website from which you do want content available to search engines, then it's still a website and you want to be careful about which bits you render using javascript, Adobe Flex, Microsoft Silverlight or other similar technologies. On the other hand, if there is content which makes no difference if it was indexed, then it's probably a web application.
The way I got around this little problem for the Mobs website was to copy the content and drop it into the host html page as a hidden div. It's all there for the search engine, links included, but is never actually visible to the end user. Of course, I was able to hack my way out of the situation because the amount of copy was miniscule. Hacks never scale too well, unfortunately, so someone choosing to dynamically populate large quantities of copy in a website which should be searchable might get themselves into a bit of a mess.

Update: 2007-05-03
I am by no means trying to actually identify the differences between a web app and a website, but rather emphasise the importance of identifying content which we want available to search engines quite early in the development process. Designers and developers need to ensure that this content is rendered in a manner which makes it accessible to a crawler. Given the amount of traffic many websites derive from Google, having important content served through flash or rendered dynamically using javascript could drastically reduce referrals from Google search.

Update: 2007-06-07
There were several thoughts which came out of this, one of them being that the whole model of web development is pretty messed up for certain kinds of applications. I've written a post explaining what I mean by this and why we should have our business models on the browser in javascript and use AJAX only to keep them synced with the server. You can find it here.

You may also want to read: When should you choose Google's GWT for your web app?
You may also want to read: Bringing business logic to the browser, or why you should develop in JavaScript