The Artima Developer Community
Sponsored Link

Leading-Edge Java
Erich Gamma on Flexibility and Reuse
A Conversation with Erich Gamma, Part II
by Bill Venners
May 30, 2005

<<  Page 3 of 3


The problem of frameworkitis

Bill Venners: What is the difference between a framework, a platform, and a toolkit, and what are the different flexibility needs?

Erich Gamma: With a platform I associate long term stability. It is safe to build on top of a platform. A platform makes compatibility guarantees. Frameworks often do not have this quality and I have seen many framework failures with regard to stability. If you look at Eclipse, yes it includes frameworks, toolkits, and provides platform APIs. All of this is bundled as plug-ins. Frameworks abstract and provide higher level default functionality. To do so the framework needs to be in control. This loss of control can lead to what is sometimes called frameworkitis.

Bill Venners: You mean the disease of wanting to make frameworks out of everything?

Erich Gamma: Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it. It's fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it's difficult to bend the framework in a direction it didn't anticipate. Toolkits do not attempt to take control for you and they therefore do not suffer from frameworkitis.

Bill Venners: And toolkits don't because...

Erich Gamma: With toolkits you create and call toolkit objects and register listeners to react to events. You're in control. Frameworks try to be in control and tell you when to do what. A toolkit gives you the building blocks but leaves it up to you to be in control.

Bill Venners: So a framework might be like an EJB container, because I subclass to create an EJB.

Erich Gamma: Right. Also, if we do frameworks, we try to make them small frameworks. We prefer many small frameworks over one heavyweight framework.

Bill Venners: Why?

Erich Gamma: Because the bigger the framework becomes, the greater the chances that it will want to do too much, the bigger the learning curves become, and the more difficult it becomes to maintain it. If you really want to take the risk of doing frameworks, you want to have small and focused frameworks that you can also probably make optional. If you really want to, you can use the framework, but you can also use the toolkit. That's a good position that avoids this frameworkitis problem, where you get really frustrated because you have to use the framework. Ideally I'd like to have a toolbox of smaller frameworks where I can pick and choose, so that I can pay the framework costs as I go.

Next week

Come back Monday, June 6th for the next installment of this conversation with Erich Gamma. If you'd like to receive a brief weekly email announcing new articles at Artima Developer, please subscribe to the Artima Newsletter.

Talk back!

Have an opinion about the design patterns topics discussed in this article? Discuss this article in the Articles Forum topic, Erich Gamma on Flexibility and Reuse.


[1] Erich Gamma is co-author of Design Patterns: Elements of Reusable Object-Oriented Software, which is available on at:

[2] Erich Gamma is co-creator of JUnit, the defacto standard Java unit testing tool:

[3] Erich Gamma leads the Java development effort for the Eclipse tool platform:

[See also] Contributing to Eclipse: Principles, Patterns, and Plug-Ins, by Erich Gamma and Kent Beck, is available on at:

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

<<  Page 3 of 3

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use