How much OO is too much OO?
in [OOP]
|
Prev: Associate Objects using domain ID or using object references?
Next: Survey about Visual Annotations for Software Models
From: Veloz on 23 Sep 2007 15:10 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
From: Ed Kirwan on 23 Sep 2007 17:40 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
From: topmind on 23 Sep 2007 19:38 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! You will find a wide variety of opinions and nobody will agree. I personally think OOP is mostly hype and should be used sparingly, but I get chewed out by OO zealots for this view. Until the zealOOts prove OO is better with actual inspectable code semi-relevant to my domain, I'll go with what I feel is best. In short, don't let zealots drive your design. > > Michael -T- oop.ismad.com
From: S Perryman on 24 Sep 2007 04:00 "Stefan Ram" <ram(a)zedat.fu-berlin.de> wrote in message news:interfaces-20070923212025(a)ram.dialup.fu-berlin.de... > Veloz <michaelveloz(a)gmail.com> writes: >>Should you really always have abstract base classes > This question does not arise in object-oriented languages > (like Smalltalk or Lisp), because they do not have static > type-checking. Lisp envs do have static type checking tools. And have done so for years. That is why OO Lisps (CLOS etc) are so much better than Smalltalk : better OO constructs (multiple inheritance, around methods) and better "in the main" programming envs (strict type checking available on demand) . > So-called "object-oriented" languages, like Java or C++, > use static typing and thus required an interface or > an abstract base clase for static type checking. Someone doesn't understand the difference between strongly- typed OO prog langs for which type substitutability = inheritance (the Simula lineage) , and those for which type substitutability is based on different models (structural equivalence etc) . A common mistake found in OO FWIW (the difference between strong typing, static typing and type substitutability) . Regards, Steven Perryman
From: S Perryman on 24 Sep 2007 04:14
"Veloz" <michaelveloz(a)gmail.com> wrote in message news:1190574633.412422.200360(a)w3g2000hsg.googlegroups.com... > 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. Quite reasonable. > 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. Quite reasonable. > 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? I think you've answered your own question. There are a ream of quite reasonable principles that one can apply to s/w development. The problem is that these principles are not orthogonal. The use of one may have consequences for others. The heuristic is to know as many of these principles as possible, and their relationships to each other. Then, for the problem in hand you are likely to most devise the best solution. This is what education and experience are all about. Failing that, a good objective judge is ROI. For whatever you wish to do, how much effort did it take to do, and what benefit did it give you (reuse etc) . ROI = benefit / effort. Regardless of whatever principles you use, IMHO the ROI tends to be a harsh but honest judge. Regards, Steven Perryman |