Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Can I avoid using a global?!

Reply
Thread Tools

Can I avoid using a global?!

 
 
mike3
Guest
Posts: n/a
 
      11-22-2011
On Nov 22, 7:08*am, Goran <(E-Mail Removed)> wrote:
> On Nov 22, 11:02*am, mike3 <(E-Mail Removed)> 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 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.
>


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

But I fail to see how the display ends up being one of those. It's
just
a display.

 
Reply With Quote
 
 
 
 
mike3
Guest
Posts: n/a
 
      11-22-2011
On Nov 22, 4:03*am, Goran <(E-Mail Removed)> wrote:
> On Nov 22, 11:09*am, mike3 <(E-Mail Removed)> wrote:
>
>
>
> > On Nov 22, 2:36*am, Goran <(E-Mail Removed)> wrote:

>
> > > On Nov 22, 5:08*am, mike3 <(E-Mail Removed)> wrote:

>
> > > > Hmm. Now I've got another question. In this program, I have a number
> > > > of
> > > > objects that represent various parts of the screen to draw in
> > > > ("windows").
> > > > These are "global" to the source code file that handles the display,
> > > > but
> > > > are not accessed anywhere outside that -- or at least not visibly,
> > > > since
> > > > there are functions that can be called from outside that use them. Is
> > > > this
> > > > global bad? If so, what can be done to replace it?

>
> > > > Namely, I've got some stuff like:

>
> > > > --- Code ---
> > > > DisplayWindow *msgWnd, *gameWnd, *statsWnd;
> > > > ("globals" within the source file UH OH)

>
> > > > ...
> > > > (Functions that use them -- this is all you see from "outside")
> > > > void InitializeGameDisplay()
> > > > {
> > > > ...}

>
> > > Your problems start this function. If you don't call it before any
> > > other function, your code will pretty likely crash (e.g. because it
> > > initializes your "globals", and some other function uses them, and if
> > > Init... wasn't called...). And there's a way to explain, through code
> > > organization, proper call order. E.g.

>
> > > class GameDisplay
> > > {
> > > private:
> > > * DisplayWindow gameWindow, msgWnd, statsWnd;
> > > public:
> > > * void Whatever()
> > > * { use gameWnd, msgWnd, statsWnd... }

>
> > > };

>
> > > If you do the above, you can't make a mistake and not call Init (Init
> > > just became the constructor of your GameDisplay). So perhaps you
> > > should try this line of thinking.

>
> > Yes, I know -- I didn't like the "Init()" function there either --
> > "Init()"
> > functions are bad.

>
> > > And then, in your main() (warning: IMAGINARY CODE):

>
> > > int main()
> > > {
> > > * GameDisplay display;
> > > * Game game(display);
> > > * game.Run();
> > > * return EXIT_SUCCESS;

>
> > > }

>
> > > Goran.

>
> > Just thought of something like that. But isn't "game" a singleton
> > there?

>
> 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 .
>


So singleton isn't just "having an object of which you happen to only
have one of".

> > Or is the "bad" kind of singleton the one
> > that acts like a type of global (i.e. if "Game game" were outside
> > main() and accessed all over the program)?

>
> Yes. You also seem to equate a singleton with a global variable .
> Not the same either.
>
> Goran.


I've heard that they can _act_ like a global, not that they _ARE_ a
global.
 
Reply With Quote
 
 
 
 
Stuart Redmann
Guest
Posts: n/a
 
      11-23-2011
On Nov 22, Stuart Redmann wrote:
> > Seriously, finding the
> > proper design is magnitudes more difficult than getting things just
> > done. So you'll get discouraged over getting things tidy right from
> > the start. Most beginners stop working on some project because they
> > struggle with the wrong objectives (not that I mean that you are a
> > beginner).


On 22 Nov., mike3 wrote:
> 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".


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.

Regards,
Stuart
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      11-23-2011
On Nov 22, 9:32*pm, mike3 <(E-Mail Removed)> wrote:
> On Nov 22, 7:08*am, Goran <(E-Mail Removed)> wrote:
>
> > On Nov 22, 11:02*am, mike3 <(E-Mail Removed)> wrote:

> <snip>
> > > However, I've already made a fair number of "working" programs. But
> > > does this mean it is OK to use these "bad" things so long as you can
> > > make it work? But what would _maintaining_ that program be like?

>
> > You have to find this out by yourself . Seriously, doing "good"
> > things means understanding why they are good. One of best ways to find
> > out why is to do bad things and hopefully learn from mistakes.

>
> 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?


Well, what about it? I mean, if it works, good. If you know why it's
badly written, also good. If you find it hard to work with later, bad,
but at least you have a working version right now, and hopefully you
see first hand, from that working version, what works and what
doesn't.

Goran.
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      11-23-2011
On Nov 22, 9:46*pm, mike3 <(E-Mail Removed)> wrote:
> On Nov 22, 7:08*am, Goran <(E-Mail Removed)> wrote:
>
> > On Nov 22, 11:02*am, mike3 <(E-Mail Removed)> 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 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.

>
> 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.
 
Reply With Quote
 
Krice
Guest
Posts: n/a
 
      11-23-2011
On 22 marras, 02:07, mike3 <(E-Mail Removed)> wrote:
> avoid using a global here since I've heard that globals are "bad".


Don't believe everything you hear. Globals are ok if they don't
mess up things. I think big closed sub-systems can be global,
because there is usually one instance. So there is no reason to
pass it around in parameters, just extern it and use the
global handle. In my programs a GUI is one example of a global
instance.
 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      11-23-2011
On Nov 23, 1:02*am, Goran <(E-Mail Removed)> wrote:
> On Nov 22, 9:46*pm, mike3 <(E-Mail Removed)> wrote:
>
>
>
> > On Nov 22, 7:08*am, Goran <(E-Mail Removed)> wrote:

>
> > > On Nov 22, 11:02*am, mike3 <(E-Mail Removed)> 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 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.

>
> > 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?
 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      11-23-2011
On Nov 23, 12:04*am, Stuart Redmann <(E-Mail Removed)> wrote:
> On Nov 22, Stuart Redmann wrote:
>
> > > Seriously, finding the
> > > proper design is magnitudes more difficult than getting things just
> > > done. So you'll get discouraged over getting things tidy right from
> > > the start. Most beginners stop working on some project because they
> > > struggle with the wrong objectives (not that I mean that you are a
> > > beginner).

>
> On 22 Nov., mike3 wrote:
>
> > 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".

>
> 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)?

 
Reply With Quote
 
Stuart Redmann
Guest
Posts: n/a
 
      11-24-2011
On 23 Nov., mike3 wrote:
> 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)?


Yes, that's how I'd do it.

Happy coding!
Stuart
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      11-24-2011
On Nov 23, 10:25*pm, mike3 <(E-Mail Removed)> wrote:
> On Nov 23, 1:02*am, Goran <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 22, 9:46*pm, mike3 <(E-Mail Removed)> wrote:

>
> > > On Nov 22, 7:08*am, Goran <(E-Mail Removed)> wrote:

>
> > > > On Nov 22, 11:02*am, mike3 <(E-Mail Removed)> 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 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.

>
> > > 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using enums to avoid using switch/if aks_java Java 30 03-25-2010 11:48 AM
Can't avoid "References to generic type List<E> should beparameterized" warning here can I ? Sébastien de Mapias Java 7 05-29-2008 06:52 PM
Avoid having a SQL express for web parts and avoid personalization Roger23 ASP .Net 2 10-12-2006 10:54 PM
using TagPrefix to avoid having @ Register directives on pages using custom controls Shan McArthur ASP .Net Building Controls 2 06-30-2005 02:37 PM
Avoid wasting time or how to avoid initialization Alexander Malkis C++ 8 04-13-2004 11:23 PM



Advertisments