comp.lang.ada
 help / color / mirror / Atom feed
From: Hubert <herrdoktor@fumanchu.com>
Subject: What is your opinion on Global Objects?
Date: Mon, 17 Nov 2014 17:36:44 -0800
Date: 2014-11-17T17:36:44-08:00	[thread overview]
Message-ID: <Joxaw.777571$yK.135556@fx14.iad> (raw)

This is not an Ada matter per se, but since I see such a vigorous 
discussion about the OOP topic in this forum I thought I'd ask this 
question here which has kept me thinking for a while and I wasn't able 
to find a satisfying canonical statement on this. Some say this and 
others say that, so I think I'd ask for opinions here so that perhaps I 
can form my own at the end.

Here is the question. Assume you have a large software system. Let's 
take the system for instance that I am involved in now as part of my 
work which is a multiplayer Client Server game. It is written in C++ but 
that shouldn't matter for the purpose of this topic.

There are "entities" on the server side that need to be accessed nearly 
everywhere. These entities best fit the Singleton Pattern because there 
is really only one instance of them, ever. For instance the class that 
handles the internet access and all client connections. Or the Ram based 
database that holds all the game objects. There is also the 
representation of the 3D world on the server side which is used for 
position check and all sort of 3D information.

These entities must be accessible from many locations in the code, 
although the region where access is needed can be somewhat restricted 
for instance the internet channel must be accessible for all player 
initiated actions but also by the User Agents that handle open windows 
on the player client and so on.

So my question is basically, is it OK to make these entities available 
through global access variables, or should they all be passed as 
arguments to function calls? We all know global objects are bad (not to 
mention that theorists heftily denounce the Singleton Pattern as bad, 
but, hey there is only one way to the internet and only one database, 
I'm sorry) but we also know that it is bad to carry "tramp data" through 
multiple levels of function calls when the functions do nothing with 
that data but pass it on to lower functions.

Global access can not really be tested in unit tests because they can 
not be passed as parameters. That's my greatest objection with the 
global concept but I dont want to pass 3, 4 or 5 parameters to every 
single function because a function called 5 levels below that call level 
might need access to those objects.

I don't think there is a silver bullet here but I would really love to 
hear what others think about this problem, specifically in an 
environment and with the examples I have shown here.

Thanks

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com


             reply	other threads:[~2014-11-18  1:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18  1:36 Hubert [this message]
2014-11-18  2:52 ` What is your opinion on Global Objects? Jeffrey Carter
2014-11-18  3:08   ` Hubert
2014-11-18  3:16     ` Shark8
2014-11-18  5:09     ` Jeffrey Carter
2014-11-18 11:23     ` Brian Drummond
2014-11-19  2:50       ` Hubert
2014-11-19  3:03         ` Jeffrey Carter
2014-11-19  9:13           ` Hubert
2014-11-19 10:22             ` J-P. Rosen
2014-11-19 17:37             ` Jeffrey Carter
2014-11-20 16:34         ` Stephen Leake
2014-11-20 21:11           ` Adam Beneschan
2014-11-21 15:25             ` Stephen Leake
2014-11-21 21:53             ` Randy Brukardt
2014-11-21  1:25           ` Hubert
2014-11-21  3:00           ` Brad Moore
2014-11-19 10:11   ` Jacob Sparre Andersen
2014-11-20  6:21     ` Hubert
2014-11-18  8:54 ` Dmitry A. Kazakov
2014-11-20 20:33 ` sbelmont700
2014-11-20 21:35   ` J-P. Rosen
2014-11-21  1:02     ` sbelmont700
2014-11-21  1:31       ` Hubert
2014-11-21  9:01     ` Dmitry A. Kazakov
2014-11-22  7:46       ` J-P. Rosen
2014-11-22  9:02         ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox