Re: OO debate: assuming type of containing object

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On 2007-11-02 11:11:07 -0700, "John A Grandy" <johnagrandy@xxxxxxxxx> said:

[...]
The debate is as follows: I argue that there are other ways for
UserControls to trigger functionality provided by containing objects.
Events are one such mechanism. I do not think that portability of objects
should be compromised in favor of coding convenience.

Others argue that for our project there is no anticipated need to ever use
WebForms that do not derive from CorePage. Further they argue that making
such an assumption is non-agile ( "agile" being a buzzword of such import on
the current sw dev scene that those arguing against "agile" are branded as
witches and burned at the stake).

Not to suggest that there's any value in using the latest buzzwords to justify one's position (especially when they seem to be misused...how is locking yourself into a specific design supposed to be "agile"?), but at least from what you've posted it's not clear to me that your position is the correct one.

Nothing about the example you provided suggests an obvious event-based interface, nor do I feel that using an event necessarily avoids the issues with respect to one class making assumptions about another. In particular, if you could define a general-purpose event that satisfies the need for generality, you could define a base class or interface that does the same thing.

IMHO, events are useful for a specific purpose, related to supports a particular kind of callback mechanism. They are orthogonal to the question of inter-class dependency.

Now as far as that question goes (the one of inter-class dependency), I'm all for designing code so that it can be reused, but I'm also not in favor of obfuscating a design just so that you can keep your objects separate. If an object truly depends on the specific behavior of another object in some way, then I don't see any problem at all representing that in the class design.

In the example you posted, as near as I can tell your control class _does_ in fact depend on the CorePage class. Assuming it's a valid dependency, I don't see any way around having your control class refer specifically to the CorePage class.

That's not to say you can't create a reusable design. While you've provided very little in the way of specifics regarding the design you're dealing with, you certainly could separate your class hierarchy out so that you parallel the dependent components. Specifically, have both custom base page and control objects rather than just a custom page object. In your control classes, put into the base class the functionality that can be written dependent only on the original base Page class, and put into a derived class the more specific functionality that is dependent on your custom derived CorePage class.

In that way, if you do need to reuse the control code that isn't dependent on the custom CorePage class, that's easily done. At the same time, you have a derived control class that can make whatever assumptions it needs to about the CorePage container instance.

If the above does not make sense in your scenario, I'll suggest that your question is just too ambiguous. If you want a more sensible reply, you should post a more concrete example. In particular, a very simple example of each of the two designs you are trying to compare, illustrating the class hierarchy and an example of the inter-class dependency that concerns you. With an example like that, it will be much easier to understand the question, as well as easier to understant your suggestion that an event-based solution would be better, and finally easier to comment usefully, providing specific alternatives to the example you provide.

Pete

.

Relevant Pages

  • support for F90/F95 in SCons
    ... now has support for F90/F95 and the automated dependency checking ... line EXCEPT there is a design flaw if that multi-USE line is commented ... references it is in the source file that contains the INCLUDE statement. ... I think SCons holds a lot of promise in terms of being able to make the ...
    (comp.lang.fortran)
  • Re: Can extra processing threads help in this case?
    ... priority inversion can only ... occur with some sort of mutual dependency. ... like you want (but the design you ...
    (microsoft.public.vc.mfc)
  • Re: Code Guidelines
    ... Design decisions based on the author thinking that the design is "cool" ... It is also possible to create a dependency cycle. ... That's only your opinion. ... _humble_) opinion about programing on ECMAScript. ...
    (comp.lang.javascript)
  • Re: Question on OO Principle
    ... 1, regarding Open-Close ... The Open-Closed Principle is a good practice for the design of ... in the dependency between high level components and detailed ... As with the OCP, your example deals with object creation, not ...
    (comp.lang.java.help)