Global in multiple files

Artur Skura arturs at iidea.pl
Sun Jun 10 16:12:51 EDT 2001


On Sun, 10 Jun 2001 21:55:17 +0400 (MSD), Roman Suzi <rnd at onego.ru> wrote:
>On 10 Jun 2001, Artur Skura wrote:
>
>>>Why do you need global variable in the OOP design anyway?
>>
>>I knew you would say that! ;)
>
>Yes, of course. Because in True Object Design there is no place for
>anything global. You have to make some class instance of which will manage
>userlist.

Mhm. It seems a little too much overhed for a simple list of users.
The problem is I need it in many places. So even if I create class
ManageUsers, set userlist=ManageUsers(), then userlist.add(user),
it will not solve my problem - it might solve for one class only,
so probably I need to rearange everything.


>>I just want to keep this one little global, userlist, in order
>>not to do some strange acrobatics later. It's clean, simple,
>>keeps the number of arguments to pass to ther functions small etc.
>
>After seven years of trial and error I could say that I begin to
>understand OOP ;-)
>
>I thought that way about arguments too. It only says that your object
>design is not done right way. (It usually happens when it's first try
>anyway).

The problem is how to do it in this case? It seems this is not
exactly within the scope of this group. But the necessity of
having userlist available from (almost) everywhere seems still
obvious to me.

>>>I blame myself each time I maintain code with global variables:
>>>the code can't be easily reconfigured, creates other problems.
>>>Globals are allright only in short scripts which has no chance
>>>to grow larger.
>>
>>In this case it fits perfectly. I need to acces userlist from any place,
>>any moment.
>
>Maybe some object could be used to represent the functionality with a
>proper method. For example, AuthoriseUser(). It's a singleton in your
>situation. But if later you decide to have more userlists, you could add
>it to authorisation chain.

No, that part of the code (authorisation etc.) is not important now.
It all will be rewritten, anyway. But I need to be able to know
the value of userlist from within instances of TS_Command.Handle(),
also from my main module, and - because the project is a little 
specific - from TS_System and maybe some other classes. 
So some solution would be to pass userlist as an argument of TS_Command
instance, but somehow it won't work.


>>OK, suppose I want to do away with global userlist.
>>I want to pass it to TS_Command instance. Will it work? No. Why?
>
>You still think in terms of structural design. Even modular design already
>has some precautions against globals. Objects are here to completely
>eliminate the problem.

Tell me how :) I think maybe I', stuck against some exception
- I really need this list everywhere...

>>I have no idea... You see, I don't want to stick fanatically to my
>>global, any solution is fine, provided that I can split my code
>>and see it working as before, when it was all in one file.
>>This 'userlist' is my last obstacle.
>
>It's not. It's just first iteration of object analysis/design/programming
>you did. (In fact, your classes has hard-coded many things. Probably you
>will want to change this in the future.)

For sure - I'm jus experimeting, it will al be rewritten, maybe
in another language, I just want to check out different ways
(Ruby seems elegant, also I spare some finger-gimnastics when
I have to change indentation of a whole function only because I
added one condition etc.)

>It's real fun to return to the same design after some time
>and look at it critically.
>
>Thus, I do not critisize you here. I am trying to express what I myself
>felt when I tried to reimplement something with objects. At first try
>you have objects wrong. (This is seen from the amount of cross-usages).
>
>It's a painful process which decreeses quality of the code at first. But
>then it starts to pay off. Bad object design is worse than bad structural
>one, someone said, but good OD is better than good structural.
>
>Try to rethink your design. Maybe your code will have other
>classes than you have now, and will be less lines.

Could you suggest some good books about OO? 
I want to make things easy for someone who might want to add
functionality to that code, so it must not be ugly.

(BTW I would like to thank other people for pointing out the
possibility of having global.py module etc. Yes, it solves my
problem for now, but maybe I should really redesign it as Roman
suggest to eliminate the need. No, I still don't know how :))

Regards,
Artur
-- 
http://www.wolneprogramy.org

"Jakos nie kusi mnie perspektywa zostania wsiowym glupkiem
znajacym sie tylko na komputerach i zarabiajacym mnostwo kasy" -- lcamtuf



More information about the Python-list mailing list