Comments on: Anti-patterns in Code: Ubiquitous HashMap http://www.pathf.com/blogs/2008/03/anti-patterns-i/ Running commentary about agile development, user experience design and Ajax. Thu, 08 Jan 2009 19:05:52 +0000 http://wordpress.org/?v=2.5.1 By: WarpedJavaGuy http://www.pathf.com/blogs/2008/03/anti-patterns-i/#comment-87 WarpedJavaGuy Wed, 05 Mar 2008 04:56:03 +0000 http://www.pathf.com/blogs/?p=68#comment-87 <p>a.k.a. The Kitchen Sink Design Pattern</p> <p>Problem:<br /> The data requirements keep changing but the interface must remain constant.</p> <p>Solution:<br /> 1. Create a kitchen sink for storing an unlimited number of objects of any type<br /> 2. Create one interface with one method that accepts and returns the kitchen sink<br /> 3. Implement the same interface in all services and across all layers everywhere</p> <p>Strategy:<br /> Implement the kitchen sink using a HashMap.</p> <p>Forces:<br /> When the domain model does not matter and you just want quick and dirty access to any data from anywhere.</p> <p>Pros:<br /> - The interface will never change<br /> - The kitchen sink can never be full</p> <p>Cons:<br /> - Can grow very large<br /> - Serialization can be expensive<br /> - Synchronization can become unmanageable<br /> - Data can become volatile<br /> - Can become difficult to find the data you want<br /> </p> a.k.a. The Kitchen Sink Design Pattern

Problem:
The data requirements keep changing but the interface must remain constant.

Solution:
1. Create a kitchen sink for storing an unlimited number of objects of any type
2. Create one interface with one method that accepts and returns the kitchen sink
3. Implement the same interface in all services and across all layers everywhere

Strategy:
Implement the kitchen sink using a HashMap.

Forces:
When the domain model does not matter and you just want quick and dirty access to any data from anywhere.

Pros:
- The interface will never change
- The kitchen sink can never be full

Cons:
- Can grow very large
- Serialization can be expensive
- Synchronization can become unmanageable
- Data can become volatile
- Can become difficult to find the data you want

]]> By: Justin http://www.pathf.com/blogs/2008/03/anti-patterns-i/#comment-86 Justin Wed, 05 Mar 2008 00:55:12 +0000 http://www.pathf.com/blogs/?p=68#comment-86 <p>This is how most loosely typed languages work. Every object is a Map more or less. Passing around HashMaps is just a way of working around Java's strong typing. It can be abused quite easily of course. The problem arises when the required data for a function become ambiguous because they are all hidden inside a map and not in the method signature.</p> This is how most loosely typed languages work. Every object is a Map more or less. Passing around HashMaps is just a way of working around Java’s strong typing. It can be abused quite easily of course. The problem arises when the required data for a function become ambiguous because they are all hidden inside a map and not in the method signature.

]]> By: Ivan Moscoso http://www.pathf.com/blogs/2008/03/anti-patterns-i/#comment-85 Ivan Moscoso Tue, 04 Mar 2008 13:45:35 +0000 http://www.pathf.com/blogs/?p=68#comment-85 <p>Good point, Harry. I think it's important to understand the motivations behind the scenes.</p> <p>That said, even if one were to apply this to some code, it can't happen without keeping it tightly scoped and on a very short leash. And even then it adds quite a bit of technical debt.</p> Good point, Harry. I think it’s important to understand the motivations behind the scenes.

That said, even if one were to apply this to some code, it can’t happen without keeping it tightly scoped and on a very short leash. And even then it adds quite a bit of technical debt.

]]> By: HarryC http://www.pathf.com/blogs/2008/03/anti-patterns-i/#comment-84 HarryC Mon, 03 Mar 2008 18:27:44 +0000 http://www.pathf.com/blogs/?p=68#comment-84 <p>> ...the typical set of problems you find dealing with global variables</p> <p>> ...a reaction to an unwieldy or overly-stateless architecture</p> <p>I've seen this often when you're down to crunch-time and you need a high-level piece of data way down in the call-stack (or vice-versa) and you just can't change 1000 method signatures to include the parameter(s) by sunrise. So, you fall victim to this sort of thing.</p> <p>Another variant: Passing Parameters as a HashMap, similar to:</p> <p>void foo( Map params )</p> <p>That will bite you eventually, as well.</p> > …the typical set of problems you find dealing with global variables

> …a reaction to an unwieldy or overly-stateless architecture

I’ve seen this often when you’re down to crunch-time and you need a high-level piece of data way down in the call-stack (or vice-versa) and you just can’t change 1000 method signatures to include the parameter(s) by sunrise. So, you fall victim to this sort of thing.

Another variant: Passing Parameters as a HashMap, similar to:

void foo( Map params )

That will bite you eventually, as well.

]]>