Five Considerations for Software Architects

Recorded at:

An excellent talk of some of the real life problems that most software shops face (even ones that claim to be on the latest and greatest). However I have second thoughts about whether a factory class should have a disposal method inside it, the analogy itself does not match. An Accord gets manufactured in its factory and then goes to a junkyard 6 years (Wait... Its a Honda, not a Dodge)... 15 years later. The factory and the junkyard have two different roles, two different responsibilities. The same analogy might not apply aptly to software, but think of it, we always fetch freshly created objects from a factory, use them deep down in the business layer and then clean them up at the place where it was last used, by invoking a clean() or dispose() or destroy() method on the created object itself. Can you let me know what are the pragmatics that you had in mind, while sending it back to the factory apart from the obvious fancy api design that it has?

It's correct to note that factories and junkyards are not the same. We are, however, slightly stuck with the factory terminology and all that the metaphor entails. The problem here is that a strict reading of the metaphor is not necessarily a good guide to where you actually want to put the roles. The consideration in question was that of symmetry and the notion that collocating creation and disposal roles in the same unit is often a simpler solution in terms of both comprehension and code. This applies to standalone factories as well as objects that adopt factory roles, such as aggregates or resource pools.

There is a subtle shift in metaphor from ownership (manufacture, own and discard) to one of borrowing (borrow, use and return), a more resource-centred view of object lifecycles, both low-level resources and domain objects that have structured lifecycles with well-defined retirement/completion events.

When it comes to addressing where the disposal role should go, there are of course two existing locations that could serve: the product and the producer. The one discussed in the talk is that of the producer, i.e., a factory disposal method. The alternative that you mention, i.e., self-disposal method, is not discussed in the talk, but is an equally valid consideration (just not the one explored in the talk). My VikingPLoP 2003 paper, "Factory and Disposal Methods" (is.gd/5gKf0) discusses both variants.

Returning to the real world we may also consider that the responsibility for disposing of the Accord should lie with the original manufacturer. Just because it doesn't at the moment, does not mean that the status quo represents the most appropriate solution!

I hope that answers your question.