Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Proposal API/extension point design workshop

Hi John,

I very much agree with you that good framework design is *extremely*
important. I'm in the "framework camp" since more than 20 years.
(Erich will kill me for saying that, but the good old ET++ framework
by Andre Weinand and Erich Gamma is still one of the best OO
frameworks I have ever seen).

I think focusing on API will naturally lead to framework discussions.
Framework and API go hand in hand. Good frameworks lead to good API
and bad frameworks lead to bad API. So, yes framework discussions
should be included.

What I really want the we all sharpen our senses for good design. I
often have the problem that I see bad smelling code but I'm not
sure what is really wrong. I also helps *very* much if you have
a group of people with a similar mindset. That makes it much
easier to push for changes to the better.

So I often look at code (including my code) and I know it needs
some restructuring. But there there's always this urgent other stuff
that prevent me from cleaning up and restructuring what needs to be
restructured. I hope from the workshop to get more impulses for
more focus on great architecture...

API actually add to the problem: because once you have published an
API you cannot easily evolve it.....


I'd like to see this discussion go beyond the details of API in Eclipse
(though this is certainly necessary to discuss as well) to also include
general framework creation questions. API aside, what makes a good
framework? While the API are an important window into a framework, I've
personally seen a number of examples where over-concentration on API
definitions yields a fa├žade on questionable code base (or, more colorfully
"lipstick on a pig"). Two books have helped me in thinking about these
issues in the past:

"Framework Process Patterns" by Carey and Carlson
"Framework Design Guidelines" by Cwalina and Abrams

The first is very interesting since it talks about the process of defining
frameworks, not just the output (frameworks/API themselves). The second is
mainly for Microsoft developers (gasp!), but has a lot of ideas that can be
broadly applied to framework design.

Back to the top