Re: [eclipse.org-architecture-council] Proposal API/extension point desi

[Michael Scharf <Michael.Scharf@xxxxxxxxxxxxx>]

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.....


Michael

> 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.