Re: OO Principle - reference needed
- From: Ed Kirwan <iamfractal@xxxxxxxxxxx>
- Date: Thu, 19 Apr 2007 12:28:04 +0200
Leslie Sanford wrote:
I have a question about setting up collaborations. Let me give a trivial
example. Say an object uses a timer. It doesn't create the timer itself,
rather the timer is passed to it when it is created. The object that
uses the timer stops and starts the timer as it pleases and consumes
"tick" events generated by the timer. My question is whose
responsibility is it to ensure the integrity of the relationship between
the two object?
I'm not sure what you mean by this, "Integrity?" I presume your continued example below is an expansion, and that, "Integrity," means basically, "Who makes sure that both objects make the correct assumptions about one another?" Please let me know if I'm wrong, as I've seen this, "Integrity," a few times but am none the wiser.
To continue with the example, the consumer, i.e. the object that uses
the timer, makes certain assumptions. It assumes that when it starts the
timer, it's not already running. And when it stops the timer no one else
will start it again. In other words, it's in control of the timer.
Is it whoever set up the collaboration responsibility to make sure that
these assumptions are met? How far should the consumer go in making sure
that its assumptions are true, e.g. that the timer is running when it
should be or not?
I doubt there are any hard and fast rules. Software being what it is, anyone could create a Timer object to be, "Not running on instantiation," and a consumer object to, "Assume that newly-instantiated Timer objects are not running."
And anyone could create the same pair but with both sides agreeing that the Timer object is started by instantiation.
It's entirely up to whoever designs it.
Furthermore, if the Timer object is designed to be non-started-yet on instatiation, then the consumer object should go to precisely zero lengths to ensure that this is true. If the consumer were to doubt the Timer's state, even though the Timer has guaranteed (via documentation, for example) that the Timer object would not be running, then the consumer might just as well doubt that the Timer object it has received is a Timer at all, and if it does that, then these two objects are hardly likely to get anything useful done; they'll just sitting there, squinting suspiciously at one another.
..ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition.
Download Fractality, free Java code analyzer:
www.EdmundKirwan.com/servlet/fractal/frac-page130.html
.
- References:
- OO Principle - reference needed
- From: Nathan
- Re: OO Principle - reference needed
- From: H. S. Lahman
- Re: OO Principle - reference needed
- From: Leslie Sanford
- OO Principle - reference needed
- Prev by Date: Re: OO-Inquisition
- Next by Date: Re: OO-Inquisition
- Previous by thread: Re: OO Principle - reference needed
- Next by thread: Re: OO Principle - reference needed
- Index(es):