On Nov 22, 11:02 am, mike3 <[email protected]> wrote:
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 is to
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.
No. Singleton is a design pattern that ensures you can't possibly
have, at any given time, more than one object of a certain type, and
provides a way to access that sole instance. "Game" and "game" aren't
that. Don't equate a singleton with a local variable ;-).
Yes. You also seem to equate a singleton with a global variable ;-).
Not the same either.
Goran.
Yet if it's "magnitudes more difficult" to "find the proper design",
then how is the "make it work then re-factor/re-design" approach
necessarily "much more time-consuming" than the approach of "use
better techniques in the first place", when to do the latter requires
more time "designing"? In other words, from the way you describe it it
would be roughly equal in time requirements, just proportioned
differently:
1. the first approach takes a "great deal of time", but that great
deal of time is spent coding/re-coding,
2. the second approach takes a "great deal of time", but that great
deal of time is mostly spent "designing".
However, what if you do the "bad" thing but manage to get away with
it, i.e.
it doesn't cause a problem in the particular program in question?
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.
avoid using a global here since I've heard that globals are "bad".
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_(object-oriented_design)
Goran.
Simple:
1. great deal of time for better design + great deal of time for re-
coding
= 2 x great deal of time.
2. great deal of time for good design
= 1 x great deal of time.
Maybe one could argue that the 1st approach is more likely only 1.5
times a great deal of time as one gets valuable insights into the
shape of the problem from the previous coding phase. It really
depends.
I like the first approach more (which is roughly the Agile approach).
Management prefers the second approach: Their mental picture of the
development process is almost always the waterfall model.
So then would this mean that perhaps it might be better to just try
it with the global, then get a basic system working, and once that is
done, try and see if there's some way to rework it so as to get rid
of that global (since then one would have more of an idea of how
everything fits together, and thus could better see what alternatives
there may be to the global)?
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.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.