This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Anti-Pattern: Design by Metaphor
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
When discussing a design or requirement, instead of using
concrete examples, people use metaphors. The discussion goes on for
quite sometime, and the metaphor takes over. People begin arguing
about aspects of the design in terms of the metaphor instead of the
actual system, often forgetting about the real code.
This anti-pattern seems to emerge when people know what they want
(or don't know), but they don't know how to express it technically, or
meta-technically with use-cases,
stories,
etc.
For example:
Jasper: "The Flojam Integration Component is a system that gets the
user entered data and associated meta-data from the front-end to
all the persistence servers. What should we do?"
McTaters: "Well, you see, the Flojam Integration Component is like a
bullet train. We confine it to tracks, and it stops at stations along
the way picking up passengers."
Bobby-Lynn: "Ah, indeed, but the passengers are going to want to
bring on baggage, right? So, we racks to put their suit-cases on!"
Stumpy: "Verily it is true, my good friend. Additionally, if the
passengers pay more, a baggage-handler will take care of their baggage
for them."
Bobby-Lynn: "Excellent point. The client-code could choose between
handling it's won 'baggage,' or having the 'handlers' do it."
McTaters: "Perhaps the customers shouldn't have to know if they're
on a bullet train, or an aero-plane."
Stumpy: "Lovely!"
Jasper: "What are we talking about here? Can we just scp over a zip file?"
McTaters: "I guess...if you don't want a bullet train!"
Previous Topic
