AntFarm anti-pattern -- strategies to avoid, antidotes to help heal from

Question

I'm working on a 10 page web site with a database back-end. There are 500+ objects in use, trying to implement the MVP pattern in ASP.Net. I'm tracing the code-execution from a single-page, my finger has been on F-11 in Visual Studio for about 40 minutes, there seems to be no end, possibly 1000+ method calls for one web page! If it was just 50 objects that would be one thing, however, code execution snakes through all these objects just like millions of ants frantically woring in their giant dirt mound house, riddled with object tunnels. Hence, a new anti-pattern is born : AntFarm.

AntFarm is also known as "OO-Madnes", "OO-Fever", OO-ADD, or simply design-pattern junkie.

This is not the first time I've seen this, nor my associates at other companies. It seems that this style is being actively propogated, or in any case is a misunderstanding of the numerous OO/DP gospels going around...

I'd like to introduce an anti-pattern to the anti-pattern: GST or "Get Stuff Done" AKA "Get Sh** done" AKA GRD (GetRDone). This pattern focused on just what it says, getting stuff done, in a simple way. I may try to outline it more in a later post, or please share your ideas on this antidote pattern.

Anyway, I'm in the midst of a great example of AntFarm anti-pattern as I write (as a bonus, there is no documentation or comments). Please share you thoughts on how this anti-pattern has become so prevelant, how we can avoid it, and how can one undo or deal with this pattern in a live system one must work with!

Answer 1

I think that Parnas pretty much nailed it in On the Criteria to be used in Decomposing Systems into Modules. Each module should hide a design decision, one that may change in the future. In general, a module with nothing to hide is usually just overhead. He wasn't talking about classes exactly, but I think the reasoning still applies.

Answer 2

Thanks Glomek the article is for an interesting problem-space, going to the core of what is OO, i.e. how to design your objects...for success or failure, thanks for the link.

Oh yeah, the anti-pattern design could be called "Ant Hill", that's a clearer description I think. I do believe it is quite prevelant right now, and seems to be growing...I'm still wondering how we can get away from it in general, and write clearer, simpler code that gets the job done with just the minimal complexity needed.

Answer 3

Hi,

If is is indeed due to over design (and it sounds like it) then here are some synonyms for you:

Gas Factory
Rube Goldberg machine
Heath Robinson contraption

But my personal name for this "trying too F#$%3n hard". My condolences.

Cheers Adrian

Answer 4

Many files where one would do. Nasty. 500 objects for 10 webpages seems a crazy ratio. Have you considered running code analysis on the solution? Might give you some interesting stats to fight back with.

Also I'd call the anti-anti-pattern KISS.

Answer 5

The problem here is that your design pattern is, itself, non-OO. Start with a non-OO pattern, try to implement it as "objects", you end up with a mess.

Just because the system is written in an OOPL doesn't make the system OO.

Answer 6

If you consider that an ant farm is an efficient way to explore a complex problem space (the ant farm) through the use of simple agents (the ants) then this starts to look decidedly less anti-patternish.

Critiques of OOP based on the complexity of 'fitting it all in your head' always ignore that (a) its hard to fit all of anything in your head (regardless of whether its OO or not) and (b) that OO actively reduces the need to have it all in your head anyway