Performance Zone is brought to you in partnership with:

John Esposito edits Refcardz at DZone, while writing a dissertation on ancient Greek philosophy and raising two cats. In a previous life he was a database developer and network administrator. John is a DZone Zone Leader and has posted 320 posts at DZone. You can read more from them at their website. View Full User Profile

'Thin Patterns' for Killing Design Pattern Bloat?

  • submit to reddit

This week I read a 2010 FoSER paper on software bloat analysis. The paper summarizes a bunch of research on runtime bloat of Java applications, nicely Java-flavoring Myhrvold's Four Laws and putting solid research behind those ubiquitous war-stories. Also includes a good bibliography.

The whole text is worth reading (only 4pp), but one direction for further research -- which the authors call 'thin patterns' -- stuck out in my mind:

While design patterns have been extremely successful in helping programmers write highly-manageable code, they are the root causes of many types of runtime bloat. In many large applications, for instance, in order to implement a visitor pattern, the programmer uses inner classes to represent different kinds of visitors, which contain nothing but a visit method. Such a visitor class can be instantiated an extremely large number of times (e.g., the allocation sites are located in loops with many layers of nesting), and all objects created are identical: they have no data and are used only for dynamic dispatch. It is not free to create and deallocate these objects, and significant overhead reduction can be seen when we use only the method without creating objects.

Future research on patterns may consider the creation of a few specialized versions for each existing pattern (i.e., thin patterns), which provides different tradeoffs between inefficiency and modularity. On the compiler side, pattern-aware optimization techniques could be expected to remove inefficiencies and generate higher-quality code.

This sounded exciting, so I did a quick lit search and couldn't find any follow-up. So I emailed one of the authors, who replied (super-amazingly-quickly) and confirmed that he also doesn't know of any more recent research in this direction.

But plenty of experienced Java devs have thought long and hard about the performance effects of using design patterns. You know better than most how to write performant Java and not reinvent the wheel at the same time.

So here's a hopefully-fruitful query:

Have you run into significant bloat caused by sloppy use of design patterns? If so, have you developed more specialized patterns optimized for your applications?

And if so (and here's the fruitfullest part) have you found any of these specialized patterns useful in other applications, or are the optimizations too application-specific to be applied repeatedly?


Serguei Meerkat replied on Mon, 2014/02/17 - 6:45pm

Have you run into significant bloat caused by sloppy use of design patterns?

Yes. I certainly have.

Example: very often I can see code where a simply creation of an object would do the job quite well. Instead there would be an interface, a class implementing this interface (only one implementation) and a factory that creates an object.

Matthias Krupp replied on Thu, 2014/02/20 - 9:00am

I have found unnecessary use of patterns like factories for single implementations (like Serguei), builder classes for simple objects or the overuse of observers. But the solution was mostly deleting all the bloat and just using the core functionality.

I think the problem with patterns is, that they're a good thing for reusability, but a bad thing for simplicity. Most code doesn't get reused often, so a simple approach is much more preferable.

Developers often think 3 steps ahead, so they implement all the possible functionality they can think of, but it will never be used.

Even worse is, that if developers change projects and their replacement don't understand the pattern usage, the code is often deleted and reimplemented.

Jaime Metcher replied on Thu, 2014/02/20 - 5:23pm

I think over time some people have come to confuse patterns with boilerplate. That's unsurprising given their English meanings are close, but in programming the concepts are polar opposites. So I mentally rephrase your question to "Have run into significant bloat caused by people using example pattern implementations as boilerplate code?". To which the answer is yes.

The thin pattern idea actually is identical to the original pattern idea. Considering all the tradeoffs and optimizing for your application is at the very heart of pattern use and always has been. Anyway, if it takes a new terminology to get us back to patterns, I'm all for it.

@Matthias: Indeed. Many patterns authors document complexity as one of the tradeoffs. You should never use a pattern unless it is the simplest thing that could possibly work. But for some problems the simplest thing that could possibly work might be very complex indeed. This is where patterns help most. Again, it's all about judgement and context.

Serguei Meerkat replied on Sat, 2014/02/22 - 3:51pm

I think I one of the problems with patterns is that today new programmers learn patterns before they themselves come across a problem for which such patterns make sense. As a result many programmers learn patterns as a way to write the code instead of a way to solve a specific programming problems.

An inexperienced developer might think that over-complication is the "correct" way to write the code and feel that he did not do his job right if his code looks too simple and straightforward.

John Esposito replied on Sun, 2014/02/23 - 5:45pm in response to: Jaime Metcher

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.