Re: Design for Extension
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 17 Jan 2006 13:18:06 -0000
Martin Ankerl wrote:
> Hi! I have recently read about Design for Extension [1], which says
> that all your methods should be [...]
I tend to be extremely sceptical of prescriptive design principles. Even more
so of Names With Capital Letters.
If I ask someone why some aspect of a design is the way it is, or why something
is coded in a specific way, then I expect to get an explanation in terms of the
other aspects of the design (current, historical, or anticipated). That's to
say, I want a reasonably concrete explanation. If the author tells me that
it's because of <some Design Principle>, then s/he has told me nothing except
that s/he quite probably doesn't understand his/her own design. (The --
important -- exception to this is s/he's using the name of the Design Principle
just as a short-cut for something more concrete that s/he knows I'll be able to
recognise from the name).
In this case, the discipline of making all methods either abstract or final may
well be appropriate in some cases. But I wouldn't claim that it's appropriate
in all, or even most, cases. And the decision whether to follow that
discipline in some case should be based on the requirements of that case, not
on the tenets of some Design Principle.
-- chris
.
- References:
- Design for Extension
- From: Martin Ankerl
- Design for Extension
- Prev by Date: Re: What is the best way to achieve this? (seperate Thread for listeningto events)
- Next by Date: Re: Design for Extension
- Previous by thread: Re: Design for Extension
- Next by thread: Re: Design for Extension
- Index(es):
Relevant Pages
|
