SD East 2002

Software Development Conference, Boston

Monday, November 18, 2002

Refactoring to Patterns

Joshua Kerievsky

My notes for this session are handwritten, and I still need to type them in. Luckily for future online notes, I lost my conference-provided pen immediately afterwards, a new personal record low in pen-retention time. All the other pens I'd so carefully packed into my laptop bag were also missing, except for one felt-tip CD marker, which I had to use for conference evaluations.

Aspect/J

There was a lot to cram into this 45-minute keynote on Aspect/J and aspect-oriented programming in general. I had to stand, so I couldn't take detailed notes. It involved modifying a common behavior or activity across the methods of a wide swath of classes, called "cross-cutting", and doing all the specification in a single file for maintainability. Examples were: screen-updating code, where a list of methods of different classes that modified shapes would have a "returning" method defined in a "display-updating" aspect, all set up from one file; and logging code, which is typically spread out everywhere. The cross-cut match could be a list of literal class.method names, wildcards, or more complex criteria based on the call stack. Interesting stuff. It had good integration with Eclipse, the Java IDE that I've really got to get around to checking out. I wonder if Dylan would be more conducive to the same style of programming than the standard forms of most other languages, because of its use of generic functions instead of methods. (Generic functions aren't bound nearly as tightly to classes as methods are, so they can be located anywhere.) Aspect/J has to use a modified compiler. In any case, there are aspect-oriented extensions for other languages available too.

Patterns of Enterprise Application Architecture

Martin Fowler (martinfowler.com) gave an entertaining talk on designing data- and business-oriented applications. (Enterprise application integration has its own, different problems, and a site for that is linked from his.)

He said he was suspicious of any one "enterprise solution" that claimed to work for all problems. There's no one solution, there have to be choices.

In the rest of the talk, he went through many good patterns (which he defined as a solution to a recurring problem), which could really be used not just for business applications, but any non-trivial data-driven web application. Business logic (which he said was the biggest oxymoron in software design) is full of special cases you can't change, so you just have to deal with complexity. Referring to patterns by their names does have the effect of adding jargon to the profession, which he makes no apologies for, because it make communication more precise.

He talked about the three familiar three-tier architecture (calling them "layers", instead of "tiers", to make it clear that they can reside on the same machine or even the same process). His names for them were Presentation, Domain (business logic), and Data Source. His slides mapped those names to the levels used by common tools.

I've found the three-layer breakdown useful in the past, and think it should be used even on medium-to-small projects. I just wish the tools had better built-in support, to avoid rolling your own class libraries. Programmers have to have a lot of discipline to design well under most of the current tools, because they make it much easier to design poorly. It's the path of least resistance. ASP and PHP are particularly bad at encouraging separation of presentation, business logic, and data access, and JSP is similar by default but at least has a standard mechanism for separation, through beans and tag libraries.

On separation of presentation and domain, he gave rule of thumb: if a manager asked out of the blue for a command-line interface (or other alternate interface) to an existing project, it should be possible to add it without duplicating a single line of code.

Those comments about ASP/PHP/JSP are mine, not his, but he did mention some other products. He noted VBScript and PowerBuilder as examples of two-tier designs, making it difficult to add a web interface. And he didn't have any kind words for Java's Entity Beans, listing many deficiencies including a reentrancy problem that often leads to a hybrid transaction script / domain model design. To use the domain model in Java, he recommends POJOs (plain old Java objects).

Three Domain Model implementation types:

Transaction Script: procedural, simple, easier for non-OO designers, but scales poorly to complex scripts and can result in duplication. Typically thin separation from SQL code.

Domain Model: more object-oriented, handles complex logic better, but sometimes complex to map to the actual database.

Gauging from his past experience, he has judged the complexity crossover point to be: 7.42. He just hasn't figured out the units yet.

Table Module: recordset interface. ex: Visual Studio, with its data-bound controls. Not good at complex domain logic. One "instance" controls multiple rows, rather than one object per row.

MVC model (model-view-controller). Hardly anything since the ParcPlace Smalltalk actaully use MVC, even other Smalltalks, since the "input controller" model requires splitting all code for incoming user-events off from the drawing code, which doesn't buy you much. Since then, everything combines input and drawing into "widgets". Subsequent designs get rid of the input controller, and often replace it with some kind of intermediary between input and model. Actually makes sense on the web, though. The controller handles incoming HTTP requests, the view is the HTML output, and we already took care of the model.

He listed different controller styles, namely Front Controllers (one big one per app) vs. Page Controllers (per page).

Web developers are always having arguments about the next set of patterns, for actually rendering the output to HTML. Options are:

Template View: minimal ASP/JSP/PHP/etc. pulling data; works with WYSIWYG editors.

Transform View: XSLT, typically, generating HTML; Use template:match rather than foreach; great for XML data & can test without web server.

Two-Step View: can make global changes & multiple views, but complex; one step transforms the data to a generic screen represntation, the second "skins" it, in the words of an audience member.

Choosing object-relational mapping: table gateway, row gateway (good without a domain model), active row, data mapper--most complex; using an existing library is a good idea (including commercial tools, and others. I should check out jaxor).

Web services aren't that major a change to most of the program. They only affect presentation layer.

Remote calls are very different than local calls, in performance in reliability. Remote call (and out-of-process) latency means methods must be coarse and data transfer must be large. Remote Facade is a pattern for coarse remote interface for fine-grained local objects. A Data Transfer Object holds the data and not much else.