From: MIGUEL A. B. L. <mb...@fe...> - 2001-12-16 13:39:08
|
Mensaje citado por: Ulrich Eckhardt <doo...@kn...>: > On Saturday 15 December 2001 15:48, MIGUEL ANGEL BLANCH LARDIN wrote: > > Mensaje citado por: Ulrich Eckhardt <doo...@kn...>: > > > Furthermore, using globals also makes clear that there are only > those > > > objects. Having pointers makes you wonder if they couldn't point to > > > something > > > else. > > > > No, better to have then as params. It is not an static assignament. > > What made me suggest using globals[1] was the current code. There the > server > consists of about six objects that are bundled inside an ArianneServer- > object. There is no chance that the pointers they have would point to > anything but one of those object. So, even though they are not declared > in > the global namespace, they are de fecto the unique instance of their > class. > It took me some time and lots of reading to figure that out, making them > > globals would simply make this obvious. > > > Please it don't add anything new to the system to make them globals > while > > it remove a lot of flexibility to the system. > > What I am saying is that they are not much different from globals > already. > The flexibility is already lost due to the other code that is written > assuming that there is only one instance of the (Manager-)object pointed > to. > Commenting this assumption by making the (Manager-)objects global would > make > the code a lot more readable, thus also reducing possible bugs. The only code that is written assuming that there is only one object of each type manager is the one that dispatch the messages to the rest of Manages ( CommandManager I think ). With adding a few modifications to this code and modify the way the managers subscribe to commands we could have several managers running the same task. Globals don't do the code more readable at all, I think that the actual way is better because it show clearly the relation between managers. > [1] 'globals are evil'. So I was tought and everybody knows it. I have > recently come to not consider that true anymore. There are some things > that > _are_ global in a program: its name, the configuration, the UI. Making > those > global can save a lot of typing and, by making the code clearer, > documentation. Clearer code don't save documentation. > Even for some objects that are not necessarily unique one should > sometimes > consider making them globals: the user-database, the networking-wrapper. > If > they are mighty enough (meaning that the database can hold _all_ users > and > the networking can manage all networking at once), there is no reason > why > they have to exist multiple times. Yes, there are reasons: mainly replication and redundancy. But this is out of the scope of this discussion by now. |