Tuesday, February 28, 2006

Java Persistence - Towards a Generic DAO

Handling persistence from Java applications has possibly been one of the fiercely debated issues in all blogs today. With EJB 3.0 in the offing and already being implemented by some of the leading vendors like Oracle and JBoss, we are still debating on the usage of ORM vrs DAO. Until recently folks had been looking into ORM and DAO as competing approaches and preferred one over the other. Andy Grove has nicely laid out the pros and cons of the two approaches in his blog item.


A properly designed mid sized Java application should use both - ORM to set up the bridge between the OO application classes and the relational tables, with DAO to ensure a clean separation between the domain objects and the persistence layer. The DAO implementation provides the facades which the business/domain model uses, and enables a seamless switching of the persistence layer downstream. Hence whatever the size of the project, the DAO pattern offers one of the basic tenets of OO design - separation of concerns.


While the DAO offers a comfortable switch on the persistence/ORM layer underneath, the application can ensure a flexible DAO layer implementation by applying yet another level of indirection. Separate the abstraction from the implementation (aha! the Bridge), and you have a generic contract for your application to play with ..


public abstract class DAOBase<T extends DTOBase> {
private DAOImplBase<T> m_impl; // the underlying implementation
...
...


With the number of growing vendors offering you the best of the breed DAO solutions (BTW Firestorm from CodeFutures is really cool), this approach can give you the flexibility of switching your DAO implementation.

The application DAOs fit in the hierarchy on the abstraction side, while the various implementations (Firestorm, Hibernate etc.) subclass from the DAOImplBase.

// application DAO
public class EmployeeDAO<T extends DTOBase> extends DAOBase<T> {
...

// DAO implementation for JDBC
public class DAOJDBCImpl<T extends DTOBase> extends DAOImplBase<T> {
...


With the usual factories and utilities in place, finally the client code looks like the following:

// make the DAO
EmployeeDAO<Employee> e =
DAOFactory.getDAOFactory(DAOFactory.DAOImplType.JDBC).getEmployeeDAO();

// make the criteria
ICriteria cri = new SimpleCriteria("employee_id = 10");

// get 'em
List<Employee> es = e.read(cri, Employee.class);

Sunday, February 26, 2006

Running Backwards

Have you ever tried to run your program backwards ? That's what Brian Hayes calls Reverse Engineering in the March-April issue of American Scientist. Reversible computing, as the paper states, also holds out the promise of significantly lower power consumption - hence it may not be too late when the program on your desktop can run in either direction.

Saturday, February 25, 2006

Degree Programs and Principles of Software Development

ACM has expressed concern over the lack of emphasis on the principles of software development in the computer science and engineering degree programs. CACM January 2006 issue has identified the following deficiencies :


  1. current emphasis is on popular details and not on the basic principles

  2. education about computers limited to Web development

  3. topics are taught with a very narrow perspective

  4. important areas of discipline like real time and embedded systems are ignored

  5. lack of sense of professional responsibilities

Friday, February 24, 2006

Habitability and Piecemeal Growth

I have started reading Richard Gabriel's Pattern of Software : Tales from the Software Community for the third time - this post is going to be a reflection of this enlightening experience.

Gabriel talks about the characteristics of a software (source code) that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. This he calls Habitability, and relates this to the concept of organic order of Christopher Alexander.

Organic Order:... the kind of order that is achieved when there is a perfect balance between the needs of the parts and the needs of the whole. (Alexander, 1975)


It is this Organic Order within the piece of software which makes its inhabitants (the programmers) feel at home, which gives the particular software The Quality Without A Name (QWAN), so earnestly professed by the saint himself. The needs of the parts refers to the changes that take place in the software in course of its lifetime, which if done adaptively satisfy the needs of the whole, leading to a grand architecture of the entire system.

The other quality which Gabriel speaks about is Piecemeal Growth, which, as opposed to large lump development, makes software extensible, malleable and compliant with the changing and growing environment. Once again he quotes Alexander:

Large lump development hinges on a view of the environment which is static and discontinuous; piecemeal growth hinges on a view of the environment which is dynamic and continuous ... (Alexander 1975)


The essence of the piecemeal growth principle have been captured in some of the essential tenets of OOP as well, the design patterns which promote reusable class hierarchies and encourage an incremental development without invasive changes. The Bridge design pattern which separates interface and implementation and lead to parallel hierarchies, the Strategy pattern which allows pluggable algorithms, the State pattern which handles changing behavior when the state changes are some of the examples.

For everybody who strives to foster uncompromised beauty in programs which they develop, this book is a must read. Gabriel leads us to the road to believe that a good program is not a Superdome of New Orleans - one should be proud to make the software a habitable New England farmhouse.

Using Eclipse Effectively

Adrian has posted this nice tip in his blog.

Wednesday, February 22, 2006

Interruptible Iterators

Just completed reading Interruptible Iterators by Jed Liu, Aaron Kimball and Andrew C. Myers in POPL 2006.

Iterator is one of the design patterns which has enjoyed the maximum patronage of most language developers and implementors. Though it has been debated that the design of iterator objects in C++ and Java have been impaired by the lack of suitable control structures, we find abundance of iterator usage in both of them. But as the above paper by Liu et. al. aptly states, in the absence of higher order functions in these programming languages,
programmers commonly use iterators as clients, but usually avoid defining their own iteration abstractions, leading to interfaces that are less clean and simple than they could be.

Alternatively, functional languages like CLU, SML, Scheme, Sather and some of the modern day multiparadigm languages like C# 2.0 and Scala provide iterators through higher order functions, closures and generators as do Ruby and Python. All of them support convenient implementation of iterators with a structured coroutine mechanism in which iterator code can yield iterated values back to the loop, leading to a much cleaner syntax.

The paper in discussion, describes interruptible iterators, which handles element removal requests through an exception like semantics called interrupts. It says :
Like exceptions, interrupts are a nonlocal control mechanism; unlike exceptions, a handled interrupt results in resumption, and interrupts propagate logically downwards in the call stack rather than upward.

Interruptible Iterators differ from standard coroutine based iterators in the sense that the latter do not support imperative updates such as element removal during iteration. But interruptible iterators take an interrupt from the client code for element removal operations, performs the request and return control to the place where the interrupt was raised, typically within a loop body. The paper has lots of other details and speaks about its implementation in the JMatch language.

Oh! BTW, C++ iterators are also due for a facelift. The current C++ iterator categories bind together two orthogonal concepts: traversal and element access. Hence the Boost team has submitted a proposal for new style iterators.

Monday, February 20, 2006

Chinese Ring Puzzle, Recursion and My First Programming Language Course

It was nostalgic to see the subtleties of Chinese Ring Puzzle make its royal comeback in Fascicle 2 of Volume 4 of Knuth's classic The Art of Computer Programming. The Chinese Ring Puzzle is one of the classic examples used in undergrad CS classes to teach recursion and presents one of the most elegant algorithms incorporating two mutually recursive routines. Grady G Early had long recommended teaching Chinese Ring Puzzle as the framework for recursion to undergrad classes, since it "is not only a master example of recursion and interesting in its own right. It can also be used to generate Gray codes". It is precisely the subject of generation of Gray codes with this toy that has been treated with the usual brilliance by the master himself.

This brings me to the last part of the title of my post - has the paradigms of functional programming and recursion lost their relevance in today's Programming Language Basics course ? People coming out of undergrad CS schools all seem to have mastered Java - this is the language that they learn in the 101 course on Programming Languages. Cornell's Computer Science Program has this up in their undergrad page for Programming Languages. Among the myriads of programmers coming out of CS schools and being absorbed in the milieu of Java shops, knowledge of the basic principles of functional languages like recursion, higher order functions, function currying, closures etc. are mostly missing. Similar thoughts and apprehensions have also been expressed by Joel in one of his posts. In the current era of agile development, multi-paradigm designs, we definitely need to think flexibly - OO is not the panacea and definitely not the "fit-all" for all software designs. Many modern langugages (Scala) have combined OO with functional programming, and not without a reason - programmers need to learn with an open mind to come up with abstractions at the entity level as well as the function level. MIT Press has done a wonderful job in putting the classic Structure and Interpretation of Computer Programs by Hal Abelson and Jerald Jay Sussman online.

Saturday, February 18, 2006

Towards Pattern Artifacts

Since the publication of the GOF classic on Design Patterns, lots of research has been carried out on traceability, automation and formalizing of design patterns in the codebase. But all such efforts have mostly resulted in false negatives - in fact it has also been shown that the lack of syntactic constraints on the pattern definitions has made the pattern detection problem undecidable.
Gil and Maman in their OOPSLA 2005 paper have come up with Micro Patterns, which are mechanically recognizable and traceable, i.e. they can be expressed as simple formal conditions on the attributes, types, name and body of a software module and its components. Their work is a definite progress towards "pattern artifacts" - being at a more granular level than the classical Design Patterns, the micro patterns find their use at late design and early implementation stages of a project. Micro Patterns are, however, at a higher level than SmallTalk Implementation Patterns of Kent Beck (which the authors call nano-patterns).

Friday, February 17, 2006

Fascicle 4 is out !!

The latest from Don Knuth, Volume 4, Fascicle 4, of The Art of Computer Programming is out. Volume 4 Fascicle 4, containing sections 7.2.1.6--7.2.1.7, is titled The Art of Computer Programming, Volume 4, Fascicle 4 : Generating All Trees--History of Combinatorial Generation.

What's in an Interface ?

An interface is the contract of the abstraction with the world. As Erich Gamma states, an interface "distills the collaboration between objects" and "defines the vocabulary of the collaboration". Martin Fowler uses the nice term published as opposed to public to differentiate the interface api with other public methods.
Check out the latest in the interface contract with Christopher Diggins in his blog The Backside of an Interface. Think of interfaces as not only the published apis, but also the objects on which the abstraction depends on. Scala provides some nicer features for modular composition of interfaces through the usage of Abstract Type Members and Mixins. Martin Odersky talks about these details and how Scala interfaces go beyond the standard monolithic apis to provide a richer component model in OOPSLA 2005.
In summary, what I learnt is the observation that a formal or informal specification of a class's interface should also include the classes upon which it depends.

Bootstrap !!

Just decided to bootstrap into the blogosphere !!

This space will be dedicated to all sorts of programming ruminations - ideas, implementations, patterns .. well, anything to do with the art of computer programming.

Stay tuned !!