The Static Spider Web Pattern
While the developer lexicon is loaded up with more patterns than we can possibly ever learn, I just wanted to introduce one of the more important patterns that I think exists out there in software development. I call it the “Static Spider Web” pattern. The main driver behind this pattern is that object instantiation, allocation, and deallocation impose far too much overhead in modern programming language runtimes. Since we aren't in direct control of memory management, and since garbage collectors on systems with large amounts of memory can cause huge latency overheads, we need to find some way to minimize, at all costs, the number of objects that we allocate.
"I'm picking up your sarcasm." "Well, I should hope so, because I’m laying it on pretty thick." –Tommy Boy
First, we are going to have to just accept the fact that we will have to create a few objects. I mean, our application data needs to go somewhere, right? I'd advocate for passing the data around as parameters, but that would get old pretty quick with all of that typing. Besides, that is what objects were invented for, to be stateless data containers.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Thomas Eichberger replied on Wed, 2009/12/23 - 6:58am
Andrew Arrigoni replied on Wed, 2009/12/23 - 8:20am
Fab Mars replied on Wed, 2009/12/23 - 8:57am
Very smart article where everyone will find food for thought! Congrats.
If you're working in a container and this ones doesn't manage your instanciations, you end up working more or less like what's described above. Even if you're experienced.
The typical example was a Struts app using Hibernate a few years ago. No matter how hard you tried you were forced to "propagate static".
Then DI arrived and solved a part of the problem. You still had some static "entry points" here and there.
With nowaday's SE/EE and a handful of thoughtful developers, you can avoid that issue :) Not always though.
Dapeng Liu replied on Wed, 2009/12/23 - 10:19am
Stephane Vaucher replied on Wed, 2009/12/23 - 12:09pm
Olive Zuo replied on Wed, 2009/12/23 - 1:29pm
Artur Biesiadowski replied on Wed, 2009/12/23 - 4:44pm
Rohit Chandramohan replied on Wed, 2009/12/23 - 5:10pm
Loren Kratzke replied on Wed, 2009/12/23 - 8:37pm
Dapeng Liu replied on Sat, 2009/12/26 - 3:36am
Eran Harel replied on Sat, 2009/12/26 - 4:21am
That's a good one.
I would have laughed if I didn't have to deal with this approach on a daily basis...
It will take us years to refactor your code :P
Markus Spika replied on Sat, 2009/12/26 - 6:39am
I'd totally point at you and laugh if i wouldn't have to cry because of currently maintaining exactly that for a living. :-(
Total highlights of this article for myself:
* stateless data containers. (oximornon of the year award!)
* the obligatory class XXXManager
* the obligatory class DataLayer
* And my personal favorite: everything talking to everything via XML (bonus points if its a self-inventend object/xml mapping)
Next time you should give the XXXHelper and XXXUtil classes the attention they deserve.
Escpecially those utility-demigods that can do database queries, data correction, representation preparation and incorporate at least 25% of the businesslogic of every usecase.
happy holidays
PS.: Isn't this already known as the Cthulhu-Pattern?
Gerrit Jansen V... replied on Sat, 2009/12/26 - 7:43pm