|Re: [eclipse.org-architecture-council] 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..... 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.
Back to the top