Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Five Considerations for Software Architects

Five Considerations for Software Architects



Kevlin Henney does not make recommendations for architecting software but rather brings into discussion five considerations useful to be reflected upon: economy, visibility, spacing, symmetry, emergence.


Kevlin Henney is an independent consultant and trainer based in Bristol, UK. He has developed and delivered training courses, consultancy and software across a number of domains. He is coauthor of two volumes in the Pattern-Oriented Software Architecture series, A Pattern Language for Distributed Computing and On Patterns and Pattern Languages.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Dec 04, 2009

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Factory and Junkyard are not the same.

    by Sara Jay,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Re: Factory and Junkyard are not the same.

    by Kevlin Henney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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" ( 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p