The Disco Blog

• Agile Smells: Don’t Let This Happen To You!- I wonder how we went from “Individuals and interactions over processes and tools” to cataloging the manifold ways to practice Agile?
• Agile Versus Lean- Speaking of Agile, man, Martin’s got something to say.
• RSpec-1.1.4- Yeah, I’m a month late to this party; nevertheless, way to go team!
• Article: Best Practices for Model-Driven Software Development- Apparently, MDD “no longer belongs to the fringes of the industry but is being applied in more and more software projects with great success.” That’s super news, baby.
• Java Private Constructor Cleverness?- My friend, Hamlet has a clever format of this blog– well done, friend!
• My “Unit Test” Aint Your “Unit Test”- Great read!

It’s clear that the initial bogue bet on Java’s ubiquity in the browser, in the form of applets, never paid off– history, however, has shown that Java found its foothold on the server-side. Nevertheless, because it’s everyone’s bag, applets are still around as I run into them from time to time. Interestingly, Sun has been putting some effort into underlying engine that runs applets (the Java plug-in), which begs the question– are applets still alive? What’s more, if they aren’t (or are on life support as some have suggested), what happened to them?

Richard Monson-Haefel recently pointed me to an hip conversation with everyone’s favorite disco superstar, Ted Neward (who you may have heard blather on and on (and on!) about Scala recently) who yammers (on and on and on– in reality, only 15 minutes but they do cut him off as he’s chattering on and on and on!) about why he thinks applets effectively kicked the bucket.

Just the same, Sun hasn’t thrown in the towel! In fact, not long ago, I had the privilege of conducting a dialog with Ken Russell, a Sun engineer focused on rebuilding the Java plug-in. According to Ken, applets aren’t dead yet and are a compelling platform for building Rich Internet Applications.

Both conversations are appealing in that they shed some light on the lessons learned about Sun’s initial applet bet and where the future may be headed (regardless if applets will be with us or not). For me, I’m not sure applets are dead just yet– Ken gave me reason to believe otherwise. Have a listen to both Ted Neward and Ken Russell and decide for yourself, man!

I recently had the opportunity to discuss Scala with my friend Ted Neward for JavaWorld’s Java Technology Insider. Ted’s been talking about Scala for quite some time now and he’s the person who turned me on to this compelling functional language.

In this conversation, Ted explains what functional programming is and why people should care– he’s got some interesting thoughts regarding OO languages versus functional languages and more importantly, where each paradigm is a good fit. Scala’s definitely got some interesting features– if you are curious to hear them, then have a listen, man!

Back in the Age of Aquarius, a popular pattern emerged in the Java world dubbed “the data access object“, which essentially

“separates a data resource’s [hip] client interface from its data access mechanisms”

meaning that clients to a particular domain object were shielded from the actual implementation of communicating with a particular database. Provided that clients worked with the interface type, implementations could be switched out (the database could migrate from DB2 to Oracle, for instance or one DAO type could leverage Hibernate, another IBATIS). This pattern had the bogue consequence, though, of logically dividing up a data layer into two types– DAOs and individual domain objects.

For instance, if you had a copasetic Customer domain object, you would also have a CustomerDAO interface type– your Customer object would essentially be a struct and the DAO type would handle CRUD (create, read, update, delete) operations. If you needed to find a particular customer, you’d ask the DAO type, for example, invoking the findCustomer(long id) method on the CustomerDAO object, which would return a fully populated Customer object.

This pattern seemed well and good at the time– I admit to using it extensively on a large project ages ago (after disco though); however, after a while it seemed to be a lot of work– if, because it was my bag, I wanted a Customer object, why did I have to ask the CustomerDAO for it? Why couldn’t I just ask the Customer itself? On top of that, if I wanted to create a new Customer, I had to first populate a Customer object and then pass it to the DAO type and invoke the create method.

I’m sure at the time a lot of smart people eschewed this uptight pattern and designed more natural domain objects; but for me, the tides changed when I read an interesting article about Naked Objects and then looked deeply at Rails (and subsequently, Grails) as they came to mature– these frameworks have no notion of a DAO type– your domain object (Customer) does everything for you– you can create new Customers, save instances, find instance, etc.

I recently found myself building a domain model in Java without the luxury of Grails or GORM; however, I did employ Hibernate and Spring. My initial effort starting going down the traditional DAO-domain object pairing but I quickly found myself disgusted– as a result I started playing around with combining the duo into something as hip (and polished) as what Grails/Rails would give you. My goal, of course, to provide a domain object that handled everything rather than having clients of the domain object have to work with two different trippin’ objects.

In the end, I still have two different objects and an interface type to link them (via Spring); however, clients need only work with one hip type– the domain object. My domain objects support instance methods like create, remove, and update and class methods for find-like methods.

I nonetheless still have a DAO object– it’s essentially a Spring wired HibernateTemplate– this object supports the true CRUD logic and is directly bound to Hibernate. For example, given a Race domain object, the DAO looks like this (minus some instance and class methods, but you’ll get the point):

class RaceDAOImpl implements RaceDAO {
 private SessionFactory sessionFactory;

 public RaceDAOImpl() {
  super();
 }

 public void setSessionFactory(final SessionFactory sessionFactory) {
  this.sessionFactory = sessionFactory;
 }

 public void create(final Race race) {
  final HibernateTemplate tmplte =
     new HibernateTemplate(this.sessionFactory);
  tmplte.save(race);
}

//...

public Race findByName(final String name) {
 final HibernateTemplate hibernateTemplate = new HibernateTemplate(this.sessionFactory);
 return (Race) hibernateTemplate.execute(new HibernateCallback() {
   public Object doInHibernate(Session session) throws HibernateException {
    return session.createQuery(
    "from ... name = ?")
    .setString(0, name.trim())
    .uniqueResult();
   }
  });
 }

//...
}

Note that this class isn’t public– it isn’t intended for outside consumption– the only client to this class (which will be shown shortly) is the domain object (which lives in the same package).

With this DAO object, I extracted an interface type– RaceDAO. This interface is the link between the domain object (Race) and the DAO (that is, the domain object will work with the interface type not the implementation or because it’s everyone’s bag to describe things in terms of coupling– the domain object is loosely coupled to the DAO implementation).

interface RaceDAO {
 Collection<Race> findAll();
 Race findById(long id);
 Race findByName(String name);
 //...other finders...
 void create(Race race);
 void update(Race race);
 void remove(Race race);
}

The domain object (which clients rely on) then relies on Spring (which basically acts as a factory) and composition to expose instance and class methods that indirectly (i.e. delegate via composition) leverage Hibernate to manipulate persistence.

For instance, the Race domain object looks like a normal, hip domain object– it contains various properties (and consequentially getters and setters) related to races (races have runners and results, etc) like so:

public class Race {
 private long id;
 private String name;
 private Date date;
 private double distance;
 private Set<Runner> participants;
 private Set<Result> results;
 private String description;

 //.....more to come
}

The next step could have unfolded in a number of different ways; however, I kept on truckin’ and ended up with something that works– there are certainly pros and cons associated with my choices though (I will point those out shortly).

The DAO interface is linked via Spring in a static block in the domain object like so:

private final static RaceDAO dao;

static {
 ApplicationContext context =
   new ClassPathXmlApplicationContext("spring-config.xml");
 dao = (RaceDAO) context.getBean("race_dao");
}

Note that the type in the domain object is the interface (RaceDAO) not the implementation — Spring is returning some type that is bound to the String race_dao, which in my case is the Hibernate template type shown earlier.

Thus, because the RaceDAO is a static type, I can then expose a series of class methods on the domain object for finding particular race instances like so:

public static Collection<Race> findAll(){
 return dao.findAll();
}

public static Race findById(long id) {
 return dao.findById(id);
}
//...others...

Plus, instance methods on the domain object also delegate to the interface type:

public void create() {
 dao.create(this);
}

Now clients of a particular domain object don’t need to handle or work with various copasetic objects– they work exclusively with a domain object (much like you would in Grails, for instance). For example, the following easyb scenario demonstrates the behavior of a Race instance:

scenario "Race should support finding races by name", {

 when "the find by name method is called", {
  race = Race.findByName("Leesburg Marathon")
 }

 then "the race should have 100 runners", {
  race.participants.size().shouldBe 100
 }
}

As you see in the Groovy code above, the findByName method is a class method– it returns a Race instance, which clients can then work with.

Instance methods on the domain object work too, for example, creating a new race instance and persisting it is as easy as invoking the create method:

scenario "the domain object should faciliate creating new instances", {
 given "a new race is created", {
  new Race("SML 10K", new Date(), 6.2,
     "race the hills of Smith Mountain lake").create()
 }
 then "the domain class should actually find it by name", {
  race = Race.findByName("SML 10K")
  race.description.shouldBe "race the hills of Smith Mountain lake"
 }
}

As I mentioned earlier, there are some bogue disadvantages to this strategy– that is, because it’s its bag, the static block forces clients to load some instance of the DAO– without mocking that instance out, the domain object becomes somewhat heavy. For instance, loading the Race class with a Hibernate wired DAO means that a database must be up and running. Thus, without some mocking of the DAO interface type (and subsequent wiring of Spring) these domain objects can be hard to truly unit test.

The advantage of this strategy is that clients don’t have to deal with a DAO type– they have a more neat-o-natural interface to work with– that being the business object itself (i.e. Customer or Race or Runner, etc). There are still two objects (and a binding type) to work with; however, the DAO is hidden. And in keeping with the spirit of the original DAO pattern, implementers are free to create varying instances of the DAO (should they actually need more than one– unit testing certainly comes to mind for a need to create at least one other instance).

The data models offered by frameworks like Grails and Rails are pretty hippingly sophisticated as well as elegant; what’s more they are easy to learn and natural to use. At this point, however, GORM (Grails magic data layer sauce) isn’t available as a stand alone project for Java developers; consequently, hip developers are left to rolling their own models (which leverage Hibernate, JDBC, IBATIS, etc), modeled after said project’s elegance.

The DAO pattern as it was authored (and implemented) back in the day is heavy, man; however, by applying a bit of Spring (or some other IOC framework) and leveraging a restrictive class modifier (to thus hide objects from clients), you can create more natural domain objects that still live up to the promised flexibility of the DAO pattern. Can you dig it, baby?

My friend, John Ferguson Smart, recently authored Oreilly’s Java Power Tools, which Andrew Binstock has said is “a must-have reference for the bookshelf” of Java developers. I couldn’t agree more with Andrew and am still amazed John was able to amass so much valuable information into a veritable bible for software development.

I had the pleasure of chatting with John for JavaWorld’s Java Technology Insider before the book was published and we had a lot of fun discussing Maven 2, JUnit, Hudson, and a host of other tools. John’s got a great deal of knowledge regarding these and other tools– all you have to do is see that the book is 900+ pages to figure that out!

Have a listen to “John Ferguson Smart on Java Power Tools” and don’t forget to pick up a copy of his book– it’s a vade mecum for anyone serious about producing working software effectively.

Towards the end of 2007, I had the hip privilege of chewing the fat with Andrew Binstock for JavaWorld’s Java Technology Insider regarding the Java IDE market, which, as anyone who hasn’t been living in cave (and listening to disco) for the last 10 years knows, has gone through some substantial changes since Java’s inception.

Andrew has some copasetic thoughts to share regarding Eclipse, NetBeans, and everyone’s favorite, for pay no less, IDE: IntelliJ; plus, Andrew muses about RAD, JBuilder, and Oracle’s JDeveloper. I am a recent convert to IntelliJ, and the conversation was rather influential in convincing me of giving IntelliJ a try.

Have a listen to “Andrew Binstock rounds up the Java IDEs” and see if you agree with him, man.

My friend Venkat Subramaniam, who played a role in shaping early versions of easyb’s hip DSL, has recently published an article dubbed “Creating DSLs in Java, Part 1: What is a domain-specific language?” on JavaWorld. This is an excellent article that demystifies DSLs and demonstrates that you probably use them daily.

One of my favorite points Venkat makes is:

Simplicity is critical to the success of a DSL. A person familiar with the language’s domain must easily understand it.

He goes on to add:

Creating a good DSL is like cooking a nutritious meal; just like you want kids to eat vegetables without realizing and fussing over them, you want clients to use your DSL without worrying about its syntax.

Because it’s their bag, this notion of simplicity has been a guiding principle for the easyb team; yet, striving for clarity, conciseness, and expressiveness (other points Venkat goes on to make) within a DSL is harder than you think! You only need look at a classic make file to see, in my opinion, a DSL that creates a lot of fuss, baby.

Check out Venkat’s copasetic article and while you are at it, don’t forget to check out easyb, man!

A most lucky bag, baby:

• Unit tests are not integration tests- John’s got a handy technique for categorizing tests via Maven 2.
• The Handiest Java Book in Years.- Speaking of John, my friend Andrew has a stellar view of John’s latest book, Java Power Tools. I couldn’t agree more with you, Andrew!
• Is the popularity of unit tests waning?- Speaking of Andrew, he’s got a great post here with a lot of insightful comments. Well worth the read, man!
• Automation for the people: Pushbutton documentation- Paul Duvall’s got a hip article here, baby.
• When To Use Mock Objects?- This is a good read– I tend to eschew mocks; thus, when I do use them they are worth the effort and provide a good deal of handiness.
• 5 Things Grady Booch Has Learned About Complex Software- I’ll add three more:
  • complex software is hard to test
  • complex software is hard to change
  • complex software is hard to kill