What if what you’re modeling really is anemic?

I firmly agree with Domain-Driven Design, but a few weeks ago I looked back at my last several projects and thought that I may not have been adhering to it. Martin Fowler wrote about an anti-pattern called AnemicDomainModel on this page quite a while back. Looking at the last few applications I have written for this client, I basically see a whole lot of bean-like objects, that is objects with a lot of state (getters/setters) but no behavior – a big indicator of the AnemicDomainModel. How could I have fallen into this trap? I struggled for quite a while trying to decide where I screwed up and what precipitated this issue. Have I worked at a high level for too long and forgotten how to take care of the details? Have I been doing too many WebSphere installations and integration setups to do the software development? After thinking about it for a while I finally settled on the opinion that what I’ve been modeling for the last few projects really is anemic, at least from the software design/class modeling perspective, so I can dig my head out of the sand.

A journey ‘Back to Smalltalk’

I read a blog post about a developers journey from Smalltalk to PHP to Ruby and back with probably a bunch of other stuff mixed in between. In this post, the author puts into words many of the things I have wondered about for the last several months. I am by no means a Ruby or Ruby-on-Rails expert, but I have messed with it enough. I do like it. Its nice and clean, simple to use, and easy to get up and running quickly.

I remember my transition from Smalltalk to Java. When I had somewhat mastered Smalltalk Java started to become the big thing. For some reason I felt the need to move to Java.

Saving planet Earth – Personally and Professionally

A couple of weeks ago, my wife and I rented ‘An inconvenient truth’. This is the documentary by Al Gore about global warming. In it, Mr. Gore presents pretty compelling arguments that we are headed towards great peril unless we immediately take steps to avoid it. I have long thought we were not doing right ‘by the earth’, but didnt think the effects would be evident as soon as he expressed. Fifty percent of the info I read are rebuttals to his claims and the other fifty are in support of it. After my own investigation (Google-o-rama) it seems that there is no doubting the ‘rapid trending’ in the negative direction over the last 30 years, to the degree to which it hasn’t been historically detectable over the past several hundreds of thousands of years. This affects me personally and professionally, doesn’t it?

Old Java Dogs

There was a posting on Javalobby today that interested me. It was basically in response to a post by Yakov Fain, a well known java ‘opinionist’ (my term), where he basically said he didnt want anything new in the Java Language. At a very high level I understood where he was coming from, but in practicality it was something that bugged me… and I lost any interest I may have had (and it wasn’t much – I’m not big on technology evangelists for more reasons than one. Thats another post for another day, though) in anything he had to say. Anyways, this posting on javalobby was right on. I remember when Java was the new thing… every new thought was a breakthrough.

Entering the blogosphere – with purpose.

So why do I blog? Well, a few weeks ago I heard a guy in a podcast or something, can’t remember exactly, say something along the lines of “With the way information is flowing today, and what KIDS just know about the internet and online identities, if you’re in a tech field and you don’t have an online identity in 2010 then you will be at a disadvantage to those who do.” I can’t remember the details because at the moment I giggled about it. A few days later, during my daughters 3rd birthday party at my house, I walked into my office and found my wife trying to help my nephew upload a picture she had just taken of him into his myspace page. We fiddled around with it for a bit and finally got it done. I was somewhat taken by the fact that he’s 12 years old and was talking about this friends page and that friends page, how cool they were, and how many people visited them. I decided that the guy I had heard was probably right. I wish I would have paid more attention to who he was. I do remember that he had started and sold 4 or 5 companies that were on the edge of technology – basically the commentator was saying he had a knack for seeing things coming and being right about them.

Development Guidlines for recent project

At one of my clients we were seeing the occasional spike in memory usage of their portal server. We’ve even seen some of the dreaded OutOfMemoryErrors. Most of the memory growth was natural – due to the growing usage of the portal. The errors are not natural – so something had to be done. At a minimum we needed to layout some guidelines for the developers to follow from hence forward to keep from compounding the problem.

This is a single server environment, no clustering. Over the past couple of years, the technical leadership at the client wanted to focus on speed over memory usage. In general, this meant that instead of re-executing the action phase when a page needed re-rendered, items that were needed for rendering were thrown onto the session. This alone can be considered OK in some circumstances. If the objects are small and few then it’s not that big a deal. But in a portal, almost by definition, there are a lot of applications. So if a lot of applications start throwing objects all over sessions then it can become a problem pretty quickly.

In addition to the times where the objects were small and few, there were times when it was done out of performance necessity. In one instance, searching for items in a Domino ‘archive’ takes over a minute. The fact that this might be fixable some other way aside; this is not something one would want to have happen every time you re-render the page that this portlet sits on. So you store the items on the session. The next question is how many do you store? Do you store the entire result set? Hopefully you limit it to some reasonable size, but reasonable to who?

These are a small subset of what we laid out. Note: These are definitely not specific to portal applications.

1. Limit Session Storage
   • Minimize information stored on session
   • Use hidden variables in forms
2. Do not store large collections on the session
   • Limit to reasonable size with paging (# per page, alphabetic, date range, etc)
3. Limit database result set sizes to smallest usable size.
   • If your result sets have more items than the stated threshold, don’t retrieve all of them.
   • If your result sets have less items than the stated threshold, don’t retrieve all of them unless you have to
   • If you can page through them do that.
   • Use reasonable judgment based on the ‘size’ of the objects in the result set.
4. If you are building large complex objects for each result, limit to a smaller number stored on session or use design patterns to solve the re-execute issue.
5. Use String constants when possible
   • For any re-used string values
   • Database library, table, and column names that are used more than once
6. Use StringBuffers instead of String concatenation always
7. Use client side sorting when possible
   • Single level sorts
   • Relatively small result sets
8. Release any session memory by using session.removeAttribute when that data has been consumed and is no longer needed.
9. Always cleanup resources, such as database connections, in a finally block to guarantee that they are done.

The importance of StringBuffer

I know I’ve said it a million times, its not really blog-ish content, and its documented ad nauseum all over the place, but you really need to use a StringBuffer when building large String objects from smaller String constituents. I have run across some issue with it lately so I want to add my contribution to the cause for anyone who may read this.

Take the following:

String dog = "The dog";
String cat = "the cat";
String action = "chased";

String sentence = dog + action + cat;

This code produces “The dogchasedthe cat”;

Its ugly, but I want to illustrate the big issue here.

The above code has produced 5 Strings:
“The dog”
“the cat”
“chased”
“The dogchased”
“The dogchasedthe cat”

Each of these is an object in the JVM taking up memory. And this is a very simple scenario. If we do some simple improvements that would be necessary to make this code usable look what happens:

String dog = "The dog";
String cat = "the cat";
String action = "chased";
String space = " ";

String sentence = dog + space + action + space +cat;

This code produces “The dog chased the cat” and it produced 8 Strings:
“The dog”
“the cat”
“chased”
” “
“The dog “
“The dog chased”
“The dog chased “
“The dog chased the cat”

Imagine if you are forumlating complex SQL or XML using inputs from a web form. You could create hundreds of strings per request. Its just a bad practice. Make sure you use StringBuffer.