Recorded at:

Five Considerations for Software Architects

Sections

Process & Practices,

Architecture & Design

Topics

Methodologies ,

Architecture

Tags

QCon ,

QCon London 2009

The next QCon is in London March 5-9, Join us!

Share |

RelatedVendorContent

Getting Started with Stratos - an Open Source Cloud Platform

ALM Everywhere ekit

A practical guide to choosing the right agile tools

ALM Buyer's Guide, by IBM

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   Factory and Junkyard are not the same.

   by Ashwanth Fernando

   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?

   Reply

2. Back to top

   Re: Factory and Junkyard are not the same.

   by Kevlin Henney

   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.

   Reply

• Older >