I’ve never read an OO patterns book for object level patterns, but I’m familiar with some of them. Without having read a book on them I wouldn’t want to recommend one, but I hear that the GoF (Gang of Four) books got good press from my associates who read them.

If you are new to OO, I highly recommend Object Technology: A Manager’s Guide. This book is great for programmers and managers, but once you’re done with it you can give it to your boss and sell them on the benefits of a paradigm shift (if you need to). :)

- max

Also, do you have any recommendation for a good OOD/Patterns book to keep as a reference?

Thanks,

Mark

Great question. I’ll provide a brief answer here with more details in my upcoming white paper. The shortest answer is that we use POJOs in the Spring IoC Bean Factory from the Spring Framework (http://www.springframework.org). We instantiate a delegate with access to a Spring Bean Factory in ColdFusion, and store it in a persistent scope. We then use the delegate object to make calls against our business tier APIs.

(The longer answer spans the next few paragraphs)

I’m not a fan of traditional heavyweight J2EE, which involves EJBs (more or less) as a requirement. EJBs require the J2EE container to exist, and as a result are not easy to develop and test outside of the container. For this reason, most Java developers these days are building systems with POJOs (Plain Old Java Objects), which are basically simple Java objects with no container reliance.

However, almost all objects need certain resources and services to be effective in an enterprise environment, such as a way to find other objects that they need, and access to enterprise resources (such as web services and databases).

The whole J2EE/EJB paradigm was supposed to alleviate access to these needs, but they did it by making the Java objects have to conform to the EJB spec. As soon as the objects conform to the spec, they are no longer POJOs and become hard to test/develop independently.

Spring’s IoC approach (Inversion of Control) makes the container conform to the objects, rather than the objects conform to the container. This is achieved through an XML configuration file which instructs the container how to set up the objects that use it. The objects are completely unaware of the container, which is how it should be.

A simple example: you have a business object that needs a DAO (Data Access Object). The DAO needs a DataSource so that it can access its data. Through the XML config, Spring would take care of creating and configuring the DataSource, populating the DAO with the DataSource, and populating the business object with the DAO. All of this would happen automatically and invisibly to your application and your business objects – your application would simply obtain a reference to the business objects and assume that they had everything they needed to do their jobs.

For more info, go to the Spring site referenced above and read the intros in the PDF manual (included in the standard distro), or check back for my white papers (the first of which should be appearing early next week).

- max

-Mark