Re: OO Principle - reference needed


"H. S. Lahman" wrote:
Responding to Nathan...

Hope somebody can help, I'm trying to track down a reference to the
principle:

'An object should create other objects or use other objects but not
both'

I've never seen it formally expounded. I suspect that is because it is
a bit too rigid.

There are sound reasons for separating the concerns of instantiation
(Who participates in collaborations) from those of collaboration
itself (When it is done and What needs to be done). Typically they
involve different problem space rules and policies so following good
OO principles like cohesion, encapsulation, and separation of concerns
will naturally tend to lead one to objects that were dedicated to
instantiation. The fact that 1/5 of the Gof patterns are about
instantiation is testimony to that.

However, one can also get carried away with such separation,
especially when the instantiation is trivial (e.g., calling a
constructor without the need for any data preparation or decisions for
initialization). For a dedicated "factory" object to do it thing,
somebody has to trigger it. When creating the object is trivial and
involves no special problem space initialization or identity rules and
policies, the triggering object may as well just invoke the
constructor. There is nothing to be gained by cluttering the design
with an object, a relationship, and a collaboration just to isolate
one line of 3GL code.

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?

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?



.

Relevant Pages

  • Re: Time of inactivity
    ... When your timer fires, check the time since you last saw a keyboard or mouse ... The form instantiation code should ... Now anytime one of the event handlers fires ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Time of inactivity
    ... My timer is in a separate module and I thought at Your solution. ... The form instantiation code should ... Now anytime one of the event handlers fires ...
    (microsoft.public.dotnet.framework.windowsforms)