«

On Nov 24, 6:45*am, Goran <goran.pu...@gmail.com> wrote:
> On Nov 23, 10:25*pm, mike3 <mike4...@yahoo.com> wrote:
>
>
>
> > On Nov 23, 1:02*am, Goran <goran.pu...@gmail.com> wrote:
>
> > > On Nov 22, 9:46*pm, mike3 <mike4...@yahoo.com> wrote:
>
> > > > On Nov 22, 7:08*am, Goran <goran.pu...@gmail.com> wrote:
>
> > > > > On Nov 22, 11:02*am, mike3 <mike4...@yahoo.com> wrote:
> > > > <snip>
> > > > > What I am talking about here is also known as "interface segregation
> > > > > principle": for a given part of your code, you want to pass in things
> > > > > it needs to do the work. To do that in a clean way, a good way isto
> > > > > create the interface (from the rest of your code) to another part, and
> > > > > pass that interface in. You don't want one big great massive thing
> > > > > that can do everything, and then cherry-pick what you need from that
> > > > > great big thing. That's akin to a global variable, except that you
> > > > > avoided having it as one, by passing it -everywhere- through a
> > > > > parameter.
>
> > > > However, the display isn't a "great big thing that does everything",
> > > > is
> > > > it? Aren't you talking about this?:
>
> > > >http://en.wikipedia.org/wiki/God_object
>
> > > Yes.
>
> > > > But I fail to see how the display ends up being one of those. It's
> > > > just
> > > > a display.
>
> > > It's a display who, I presume displays all sorts of stuff (text,
> > > graphics, possibly interacts with the user). But your concern is to
> > > emit messages. If so, your "clients" of the display see one great big
> > > thing that does text/graphics/interaction, and yet, they merely want
> > > to emit messages. So in that sense, it is a God object.
>
> > > BTW:http://en.wikipedia.org/wiki/Solid_%...nted_design%29
>
> > > Goran.
>
> > So then should the "display" object be partitioned up into a few more,
> > like one to do messages, one to do graphics, one to handle input?
>
> I was merely commenting on "various places" who want to "display
> messages". In general, even without knowing a lot about the rest of
> the code, I felt it's safe to say that it's a bad idea to give them a
> display object, even if it's a display that displays messages. Hence I
> reacted: passing a mere "MessageReceiver" --interface-- is better.
>
> Now, whether MessageReceiver interface will be implemented by
> DisplayWindow, or whether it will be a separate object that references
> DisplayWindow, I don't know. I would venture that a separate object is
> better because... What if you're not showing DisplayWindow object for
> message? I'd personally destroy the object: not on screen, not in
> "code". If so, you --need-- a separate object to receive messages. If,
> however, you elect to have DisplayWindow object always there, then he
> itself can be your MessageReceiver. But dig this: either way you
> decide, parts of your program that depend on services of a
> MessageReceiver --do not care-- about any of that. As long as you can
> pass them a MessageReceiver, you can do what you want "behind" it. In
> other words, you just gained a thing caller looser coupling, and that,
> in programming, means freedom .
>
> Goran.

So this would allow one to not only display messages, but also, e.g.
suppress
output by passing in a "null" (an object with "MessageReceiver"
interface
that just does nothing), or direct output to a file, or another
display, etc.
Lots of possibilities.