Summary:
Developers are often faced with decisions about how much flexibility to design into their software. In this interview, Erich Gamma, co-author of the landmark book,
Design Patterns, talks with Bill Venners about the attitude he believes developers should adopt towards flexibility and reuse.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: August 30, 2005 7:59 AM by
David M.
|
Developers are often faced with decisions about how much flexibility to design into their software. In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about the attitude he believes developers should adopt towards flexibility and reuse. http://www.artima.com/lejava/articles/reuse.htmlWhat do you think of Erich's comments?
|
|
|
I have trouble understanding what exactly is meant by Framework, Toolkit and Platform.
Perhaps some contrasting examples would help, especially showing the difference between Toolkit & Framework or Framework and Platform.
|
|
|
> I have trouble understanding what exactly is meant by > Framework, Toolkit and Platform. > > Perhaps some contrasting examples would help, especially > showing the difference between Toolkit & Framework or > Framework and Platform.
I drilled down on these when I talked to Erich, and think I got the general idea. The basic difference he was trying to draw was between frameworks and toolkits. It is a subtle distinction, but in essence his notion is that a framework burdens you by saying you have to subclass something and override methods that it will call. An example is an EJB container. Another example is a Java applet. A toolkit, by contrast, is an API that you call into, like say the collections types in java.util. So whereas you call into the methods of a toolkit, the framework uses the Hollywood principle of "don't call us, we'll call you."
He then observes that frameworks often hem you in such that eventually you end up fighting against the framework. He said he felt "platform" connoted long-term stability.
|
|
|
Get article, and I especially like the following comment, which is the reason I don't like struts:
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
|
|
|
Wow, great articles. I especially liked the introduction and description of "Frameworkitis". Currently, I believe we're experiencing the "hangover" effect from some of these grandeous "Frameworks" that were developed over the years to "revolutionize application development" in Java/J2EE. (We are starting to see that they are not as flexible/extensible as we once thought)
IMO we've also got a bad case of "Patternitis" Wonder what Gamma thinks about Sun's BluePrints?
|
|
|
Great articles! I'd like to hear more from Erich Gamma. On the topic of reuse, I'd be very interested in Erich's take on software product-lines and product-line architectures. Here is the SEI's main page on product lines. http://www.sei.cmu.edu/productlines/index.htmlA SEI specific page and quote re reuse: http://www.sei.cmu.edu/productlines/frame_report/pl_is_not.htm"In a software product line approach, the reuse is planned, enabled, and enforcedthe opposite of opportunistic. The asset base includes those artifacts in software development that are most costly to develop from scratchnamely, the requirements, domain models, software architecture, performance models, test cases, and components. All of the assets are designed to be reused and are optimized for use in more than a single system. The reuse with software product lines is comprehensive, planned, and profitable." I've taken four SEI architecture courses and I'm trying to resolve the overlap and differences with a more agile evolutionary approach to architecture. Basically how should companies with multiple products approach design, flexibility, reuse, etc. On the topic of deep plug-in architectures like Eclipse, I'd be very interested in hearing about various designs/patterns towards extendable architectures. I started this wiki page as place to collect info on that topic. http://www.c2.com/cgi/wiki?PluginArchitectureAnd this page for examples. http://www.c2.com/cgi/wiki?PluginArchitecturesAny suggestions for more info on the topic?
|
|
|
How does the engine metaphor fit in with reusability? This metaphor is used extensively in game programming, but I dont recall seeing it used much elsewhere. Is an engine just a framework, or is it something entirely different? In my mind the engine metaphor tends to imply more encapsulation, distribution, & parallelism.
|
|
|
Great article!
It is easy to talk about objects and reuse, but it is very hard to have some gravity to them. I've been a big fan of Erich Gamma for years and look forward to more articles where he expresses his ideas.
I'm also curious about his views on the semantic model of an application. That is, I find successfull reuse dependent on consistent semantics (e.g. in naming of objects, database tables, xml files, web pages, toolkits, framworks, libraries, etc.) Or rather, it is dependent on refactoring the semantic model.
The model tends to cross boundaries from the internal to the external. And in so doing, it becomes hard to refactor as it is essentially public.
I'm curious what Erich thinks about this. Perhaps he already is disucssing this topic (semantics/naming) without directly mentioning it, but to me it seems to be different than adding flexibility with respect to code constructus.
So I guess my question is, how does one develop flexibility in semantics to facilitate reuse?
|
|
|
Regarding frameworks and toolkits: I have tended to consider the difference to be about who provides the 'glue'.
I.e. a toolkit is like a collection of tools and parts and other bits that I, as the programmer, need to assemble or glue together in some meaningful way. In a framework the glue is built-in. The assembly work is already done and I just need to fabricate my specific functionality and pop it into the predefined integration points.
Using a framework can look like a great savings in time and effort until you need to do something the designers of the framework never anticipated.
I tend to favor toolkits but I also don't think there is always a sharp delineation between toolkits and frameworks. A toolkit, as Erich suggested, could include small sets of cooperating classes that might be considered mini frameworks.
The pragmatic programmers talk about 'shy' code and the advantages of loose coupling. I think libraries can provide advantages by being design 'shy', that is 'shy' about making too many assumptions about how they will be used. A library with fewer or smaller embedded assumptions carries less risk.
|
|
|
My previous statement
"It is easy to talk about objects and reuse, but it is very hard to have some gravity to them."
should read
"..but it is very hard to have gravity in those discussions. Your discussion certainly did.
|
|
|
I think a good example would be the OO mainstay: Lego bricks. If you go to Toys R Us you see two types of lego system.
There are the basic starter kits that contain a balanced set of basic building blocks that can be used to build pretty much anything: A house, a car, a spaceship. These will all have the same kind of bricky appearance though: no curves or markings.
This is what a toolkit is like. Simple and generic.
Then on the other hand there are the specific branded sets, like for Harry Potter or Star Wars.
The Star Wars sets will allow you to build Spaceships like those in star wars. They'll be sold for on specific model, but you can adapt and combine them to make up your own stuff. No your spaceships will have curves, and markings, and recognisable starwars like features. It would all be high tech though, so you wouldn't find it very good for building castles and haunted mansions. On the other hand, the opposite is true of the Harry Potter sets.
Frameworks are like this. They are designed to achieve a specific purpose, and it makes achieving that purpose much easier. However, while they provide some genericity, it also restricts you too what the designers had in mind.
|
|
|
Hmmm... I wasn't really going to comment on this Article, but maybe I should look into a bit because it sounds like there may be a move to re-define existing concepts (framework, toolkit, platform) and I don't want my understanding of what these things are become out of date :)
I actually just wanted to thank you guys who set up this site. It looks to be a very valuable development resource.
|
|
|
Oh, btw, my existing understanding of what these things are is this:
Toolkit - prefab, fully functional code. Not much flexibilty, it does what it was intended to do, and not much more. But it's easy and fast.
Framework - An API. Like MFC, or the old SDK. Or the old Borland OWL (Object Windows Libraries). Requires a lot of effort and skill to use well, but extremely powerful and flexible.
Platform - A computer and it's operating system. Examples: Development platform. Target platform. Like when I write a piece of C code on my Windows XP PC (development platform) that will be run on a Sun Microsystems UNIX server (target platform).
These concepts have been pretty static since I started as a software developer in 1990, at least. Can somebody tell me if I need to start re-thinking what these terms mean?
|
|
|
Erich Gamma kept giving Eclipse as an example but is that fair or just the easy way out?
I am writing (or at least trying to write) reusable presentation (GUI) and buisness logic code that is usable in at least the following environments:
- NetBeans (IDE and Platform) - Eclipse - J2SE native - J2EE native
The amount of "wiring" that is required in each of the above environments is excessive and I believe is caused by thinking in terms of "platforms" (i.e. Eclipse) rather than problem orientated.
The fact that neither IBM nor Sun have defined API's such that functionality written for one platform (e.g. NetBeans) is easily "rewirable" for the other platform (e.g. Eclipse) in not a very good comment on the state of affairs on reusability!
On the IDE level the requirements are identicial (the consumers and customers are the same).
JSR-198 was once very promising, but has taken almost 3 years to get from JSR Review ballot (13 yes 1 abstain 1 no vote) to Early Draft review. At one time I was holding my breath for the arrival of the first reference implementation. In the meanwhile I have given up even hoping that the JSR will ever have a reference implementation! One would assume from this interview that it should be trivial to provide an Eclipse alpha implementation for JSR-198 (thus providing a start place for step-wise refinement and prototyping).
IDE requirements IMHO are far simpler (and far more static) than real world buisness requirements.
As usual the theory is fantastic but the real world (verbal) examples are restricted to a implementations in a simplistic environment.
Eclipse consists of many millions of lines of code. How much of that code is: - Usable outside the Eclipse environment? - Actually used (unchanged) outside Eclipse?
Only after answers to the above is it at all relevent to really think about the answers given in this interview.
|
|