*
programming and human factors
by Jeff Atwood
*
Artima has another great interview series, this time with Erich Gamma. You know, Erich Gamma: Gang of Four, JUnit, Eclipse. As you might expect from such a notable developer, it's full of great advice. Like this section on avoiding frameworkitis:
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.If we do frameworks, we try to make them small frameworks. We prefer many small frameworks over one heavyweight framework. 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.
Highly recommended.
If you enjoyed that, you'll also enjoy a similar series of interviews with the Pragmatic Programmers. The entire series is linked at the bottom of this post.
"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."
Maintain it? Does Erich mean maintain the framework in context with some software system?
I agree that a large framework can be cumbersome, but a well architected framework can small when it needs to. For example, a lot of developers would agree that the .net framework is a lot of stuff. But within all that stuff (like all the stream classes), is a base class (in my case the Stream class) that will provide you with the most flexibility.
It's like a painter complaining about too many premixed colors, that there should only exist primary colors and that everything else is up to the painter to mix.
I agree that great things can be done with little, but it is the job of the developer to define his or her "little." Narrowing the scope of a framework broadens the flexibility of a project while allowing for a fallback.
I agree with Erich after using frameworks for
3 years i've learned how restrictive they can be.
Recently i've gone back to using the core httpservlet api and enjoyed it's flexibilty
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email