Re: How much OO is too much OO?
- From: Ed Kirwan <IAmFractal@xxxxxxxxxxx>
- Date: Sun, 23 Sep 2007 21:40:44 GMT
Veloz wrote:
Hello
There seems to be lots of information out there on how to use good OO
practices, principles and patterns, but it's not clear to me how far
to go with these, and when.
It seems some people go full tilt with all projects. For example, I
read one post where the author states his base classes are always
abstract and he never programs to concrete classes, but to interfaces,
and so on.
Others maintain that most of these practices are irrelevant until/
unless you need to make a change to your program and find out that
it's inflexible or hard to grow in a certain area. Or, of course, if
you know up front that a part of your design will vary, then
encasulate that part of the design.
I guess I'm looking for some advice on what a good rule of thumb is.
Should you really always have abstract base classes, even if you can't
imagine ever needing a different branch of your class hierarchy?
Should you really delegate every part of an algorithm that you can
possibly think of *just in case* you need a variation someday?
I am currently working on my first application in .NET and have re-
worked my design countless times.. sometimes feeling that my design is
very rigid because all I have are concrete classes and only one place
I can clearly see a need for some delegation .. and at others times
feeling that for just two small use cases I have created an unwieldy
amount of abstract classes, interfaces, and indireciton mechanisms.
Ugh!
Michael
Hello, Michael,
There are no strict rules that I know of.
There are no rules that say, "Use concrete base classes in these cases, but
never in those cases."
It's all judgement. (This shouldn't undermine judgement, of course: it's
judgement that keeps companies afloat and gives consumers precisely what
they want to consume.)
I can only suggest the limits within which I work: use interfaces when
dealing with inter-name-space dependencies. In other words, use Facades
once your dependencies leak between name spaces.
Your question, therefore, is at least limited (in my experience) to
intra-name-space dependencies (i.e., between classes private to a name
space); and so - and this is the point - if you make the wrong decision
then at least the damage is limited to one name space.
Yes, this is essentially raising the, "Program to an interface, not an
implementation," to name-space-level (at a minimum), but I've found this to
be a good mid-path through this particular jungle. For more, see:
http://www.edmundkirwan.com/fracdoc/frac-page10.html
--
..ed
www.EdmundKirwan.com - Home of The Fractal Class Composition
.
- References:
- How much OO is too much OO?
- From: Veloz
- How much OO is too much OO?
- Prev by Date: How much OO is too much OO?
- Next by Date: Re: How much OO is too much OO?
- Previous by thread: How much OO is too much OO?
- Next by thread: Re: How much OO is too much OO?
- Index(es):
Relevant Pages
|
