Wicket: truly OO

Object orientation has been the great software success story of the 1990's. If done well, OO programming allows to save on development costs by fostering code reuse and by improving maintainability through reduced coupling. In the next paragraphs, I'll show what is necessary to support these techniques in a web framework and how Wicket has exactly those properties.

Code reuse is achieved through polymorphism and abstraction. Polymorphism allows to share code among object that are almost, but not quite the same. You define a common superclass for those objects and override methods to implement the behaviour specific to a particular subclass. Abstraction, on the other hand, works by allowing an algorithm to treat various object the same, even if they are implemented differently. We call this programming to an interface. In Java, for example, you can call methods on an interface, even if you don't know the implementing class. But this is only possible, if we do not depend on the implementation of the object. In particular, the state representation of the object must be private to the object.

The same mechanism of encapsulation also allows to reduce coupling between modules. If I do not know how an object is implemented, I cannot have a dependency on that implementation, and I'm therefore free to change the implementation without consequences in the rest of the system. The biggest maintenance nightmare is the class that nobody will touch, because the smallest change may have unforeseeable consequences.

Since Wicket components are simply Java objects, it is trivial to apply the OO mechanisms of code reuse to create new components. There is no tag library to implement, and existing components can be customized simply be overriding the appropriate methods. In other component oriented web frameworks, there is usually a clear distinction between creation and use of components. In Wicket, there is no such distinction. You cannot write a Wicket application without creating at least one component: the home page.

Wicket's use of controlled serialization for implementing private component state, plus a couple of associated techniques (markup inheritance or the component id scheme, for example), allows for truly "black box" components. The best prof of this is the usual installation instructions for wicket component libraries: you just drop the jar on the class path. The component needs to do the rest.