Joe Rinehart

At work, I've been working on an implementation of Liferay, an open source portlet server that has a focus on content management and collaborative / social applications.  It's a good-sized departure from ColdFusion development, but I'm finding that what we in the OO ColdFusion community have learned over the past 3-4 years makes us perfectly suited to this level of J2EE development. 

On this project, I'm mainly serving as an architect and product designer, but I hit a feature / change I wanted to implement that needed to occur at the service level.  At first, I was scared - I mean, this is the big-bad scary complex world of Java.  However, once I looked at how it was put together, I realized that it's nothing but the same concepts we in the OO ColdFusion world.  Here's all I had to do:

1. Subclass (extend) the service component I needed to modify (SocialActivityLocalServiceImpl, which provides an activity feed)
2. Open a Spring beans file (ext-spring.xml)
3. Redefine the bean tag to point to my custom subclass
4. Restart Tomcat

Now that's JEE the way it should be!  Big thanks to Dave Ross and Chris Scott (and others) for knocking out ColdSpring - as well as improving my CF apps, it's taught me concepts I can definitely take elsewhere.

With an ongoing debate over me stating that generic getters and setters were a bad idea, I thought I'd take a stab at an implementation that tried to fix Peter Bells's fault with them (they're verbose) without falling into problems I had with Peter's "Generic" approach:

1. They're a direct encapsulation violation, as you have to know implementation details of the CFC to know how to use it.
2. It's based on the magic string / magic number antipattern, where strings evaluated at runtime take on API, not data, significance.
3. They don't produce an API that can be used by others, as an object has no external API describing its properties.

While I was accused of zealotry, the accusation was based on the assumption that I thought forcing people to write getFoo() and setFoo() is a hard-and-fast rule applicable to every application.

It's not.

I cooked up the following bit, following an idea Mark Mandel had a while back while discussing implicit setters. I can't claim any originality - over IM last night, Mark knew exactly what I was up to before I even told him what I was doing.

The "hack" results in a property manipulation API such as this, where you use <cfproperty> tags to declare properties, and only those marked as access="public" can have accessors and writers "generated" on-the-fly:

What I Like About It

1. Objects are still true objects - they have defined properties. Encapsulation and API definition are maintained.
2. Instead of literals (set("Name")), you work against methods.

What I don't like about it

1. The syntax is a bit weird. The equals sign is just what I see as being assignment to a property, but setFoo() doesn't have that either.
3. There's a runtime cost associated with getting all properties up an object's inheritance chain on the first get/set, and I'd find that unacceptable in a high-load app.
4. There's no type-checking, as I didn't want to add that cost or write the code for it.

Conclusion

It's an interesting experiment, but not one I'll put forth as a good technique for big apps.

Code

Here's the code that was used (obviously CF8-only):

This started out as a long comment on Brian Kotek's recent post about the ActiveRecord pattern. I figure that while I've still got some Rails-ish types irked at me, I may as well go ahead and blog a bit more about why I don't like the datacentricness of the ActiveRecord approach.

Before you fire up your flame generation script, let me say this: ActiveRecord is super-productive when you need to allow someone to edit a relational model. It doesn't, however, suit the kind of OOD-backed development I do. This post is about why.

[More]

So, what's with the guy who put together the MG:U stack calling this stuff backwords for something he pushes (OO)? I'm not writing this to start a flame war: I'm writing this because I'd like people to think about the tools they're using and the appropriate contexts for their use, and I chose a bit of an inflammatory title to get you to click. :)

[More]

In a few recent posts, there's been discussion of the validity and purpose of what's called the "Gateway" pattern in a ColdFusion application's object model.

[More]