Global in multiple files

Roman Suzi rnd at onego.ru
Sun Jun 10 13:55:17 EDT 2001


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.

>The source code is at http://arturs.iidea.pl/server.py
>and you can get 'live demo' by
>$ telnet arturs.iidea.pl 2211
>It's based on simple chat code.
>
>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).

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

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

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

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.

>Regards,
>Artur


Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Sunday, June 10, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Computers make very fast, very accurate mistakes." _/





More information about the Python-list mailing list