Design

go-restful api design

I have been using JAX-RS for many REST-based service implementations in Java.

As part of my journey into the Google Go programming language, I am exploring designs for such REST support using the standard net/http package in Go.

JAX-RS provides a set of Annotation classes which can be used to add meta-data to classes, methods and method arguments. In JAX-RS these annotation are used to specify the mapping between a Http Request to a Java method and its arguments.

Using renderSnake to build the presentation layer in Spring-MVC

renderSnake is a open-source library for creating components that produce HTML using only Java. By defining Java classes for HTML components and pages you can exploit all the language features (e.g. inheritance, composition, type-checking) and IDE tooling (e.g. refactoring, unit-testing, references search, debugging,…). In addition, renderSnake is designed to produce compact HTML in an memory efficient way.

The "V" in MVC

Basically, renderSnake is responsible for the presentation layer of a Web application. It has no dependencies with an application framework but it does provide classes to integrate with other technologies such as JavaServer Pages and Spring-MVC. Spring-MVC is a popular implementation of the MVC architecture. This pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).

Example

Below is an example of a Spring-MVC based setup of components. ProductListController is a component that is responsible to handling incoming requests. That execution starts by retrieving the Product objects (Model) through a Product Data Access Object. Then a ProductListPage object is created and asked to render itself. Each UI component that is part of the ProductListPage is asked to do the same. The response will have the resulting HTML content.
  • missing image /2011/02/spring-mvc-rendersnake.png

Controller

The method below is part of the ProductListController and is called with a prepared HtmlCanvas object that captures the request,response and output writer. Before rendering the page using the HtmlCanvas, all required domain objects are retrieved and made available to the PageContext (Map) of the HtmlCanvas object. Now the HtmlCanvas has all the information needed to perform the rendering phase.
@RequestMapping("/productlist.html")
@ResponseBody
public void showProductListPage(HtmlCanvas html) throws IOException {

        html.getPageContext().set("products", this.productListDao.getBestSellersProductList());
        html.render(new WebshopLayoutWrapper(new ProductListPage())));
}

View

Using renderSnake, the View layer is implemented by a collection of small, potentially reusable, UI component classes that are composed into Page objects that represent HTML content.

Class Head is an example UI component responsible for rendering the head section of every HTML page. It implements the Renderable interface and uses the HtmlCanvas parameter object for rendering. The HtmlCanvas object has methods of all elements (tags) in order to write HTML content. Using the HtmlAttributesFactory, you can specify the attributes for each HTML tag. By convention, the method source has a format that uses indentation to see the nesting of tags. This is not required but improves its readability.

Tiny, single-purpose class: ResultToFunctionAdaptor

Every now and then I need a small piece of functionality that perfectly fits into a single, minimal-behavior thus single-purpose class. This time I am developping a Adobe Flex application that uses the RemoteObject facilities. Before invoking a method on a RemoteObject, you have to add two event handlers that will be called with a ResultEvent or a FaultEvent respectively. Typically in the “onResult(event:ResultEvent)” function, one takes the result of the event and calls another function or update a view.

Helper classes considered bad OO

Too often developers put logic in so-called Helper classes.

This practice of SPOD (Single Point of Definition) results in a higher level of reusability, so it seems. But in fact introducing these procedural structured behavioral methods impose a rigid structure. First of all, (other) developers need to be aware that such Helpers exist to work on their objects. Secondly, because behavior that should have been defined in the class of the object, is now defined elsewhere. The possibility of re-using such behavoir by inheritance is now unavailable. You cannot just extend an Helper class too!

Application Diagnoses Itself

How can I provide programs with self diagnostic behavior? How can I implement this in a way that has low impact on the way I write programs (or Java classes to be more specific). If programs could run such a self diagnose then perhaps it takes less time to find the cause of an observed problem.

These thoughts are sprung when I found an error in an application that went into production just a few days earlier. The problem itself was easily fixed (just a typo in some properties file) but I was a bit surprised that obviously my tests did not cover this particular execution path. Sure, I should have written more tests to have a higher coverage (JCoverage can tell me what percentage), but what if I had programmed this behavior differently(how?) such that a self diagnose run would have detected it?

Don'ts

Another example of how negative publicity can have a big learning effect (if understood). From a new entry @ slashdot about Multi-links, I surfed to WebsitesThatSuck. The authors are committed to show the worst designs that live on the web.

With respect to Software Design, my dialy work, a similar initiative has been around for a few years. In response to the popular Design Patterns book written by the Gang of Four, others introduced the Anti-Patterns as a means to teach designers about the dont’s in the design of systems using Object Technology. You can contribute to them using the Anti-Patterns Wiki.