Python OOP question

[k3xji]

Hi all,

I am trying to develop a game-server in python. Design is as
following:

- ConnectionManag er - handling/distributing incoming connections
- IOManager - handling IO recv/send operations on sockets.
(inheritable)
- Socket - basic async socket object
- SocketServer - handling multiple socket object requests.
(inheritable)
- Options - holds the server options (inheritable)

I want this code to be extensible as it can be. So I have developed it
like this. I f one is going to implement some new feature, all needs
to be done is to inherit IOManager or Server object to do it.
Inheritable objects are IOManager, SocketServer and Options.

But there is some feeling about this design that it can be better.
Here is the main.py which I am using to execute the server:

from Base.SocketServ er import SocketServer
from testIOManager import testIOManager
from Base.Options import Options
from Base.Connection Manager import ConnectionManag er

iomgr = testIOManager()
opts = Options()

# calculate how many server objects to create
# according to the maximum allowed client count.
serverCnt = opts.MAX_CLIENT _COUNT / opts.MAX_CLIENT _COUNT_PER_SERV ER
Servers = []
for i in range(serverCnt ):
server = Server(i)
Servers.append( server)


cmgr = ConnectionManag er(Servers, iomgr, opts)
cmgr.start()

With current design as server object is inheritable, I need to pass it
to ConnectionManag er object. I just have a feeling that above design
is bad in the sense of readability.

Is there any paradigms. patterns specifically in Python for above like
situations, where in a library, we design some objects to be abstract
as possbile and other non-inheritable objects using the functions?

Or just any feedback on this Design structure?

[Gabriel Genellina]

Re: Python OOP question

En Thu, 25 Sep 2008 11:45:21 -0300, k3xji <sumerc@gmail.c omescribió:

Hi all,
>
I am trying to develop a game-server in python. Design is as
following:
>
- ConnectionManag er - handling/distributing incoming connections
- IOManager - handling IO recv/send operations on sockets.
(inheritable)
- Socket - basic async socket object
- SocketServer - handling multiple socket object requests.
(inheritable)
- Options - holds the server options (inheritable)
>
I want this code to be extensible as it can be. So I have developed it
like this. I f one is going to implement some new feature, all needs
to be done is to inherit IOManager or Server object to do it.
Inheritable objects are IOManager, SocketServer and Options.
>
But there is some feeling about this design that it can be better.
Here is the main.py which I am using to execute the server:
>
from Base.SocketServ er import SocketServer
from testIOManager import testIOManager
from Base.Options import Options
from Base.Connection Manager import ConnectionManag er
>
iomgr = testIOManager()
opts = Options()
>
# calculate how many server objects to create
# according to the maximum allowed client count.
serverCnt = opts.MAX_CLIENT _COUNT / opts.MAX_CLIENT _COUNT_PER_SERV ER
Servers = []
for i in range(serverCnt ):
server = Server(i)
Servers.append( server)
>
>
cmgr = ConnectionManag er(Servers, iomgr, opts)
cmgr.start()
>
With current design as server object is inheritable, I need to pass it
to ConnectionManag er object. I just have a feeling that above design
is bad in the sense of readability.

You may imitate how asyncore [1] handles channels: make the library
contain a (global) list of servers; the Server (base) constructor adds
itself to the list; and ConnectionManag er uses that list if not
explicitely supplied one.
But I'm not sure it improves readability: there is no explicit link
between the Servers you construct and the ConnectionManag er, but the
latter "magically" knows about all the formers. It's easier to manage,
though.

(I don't undersantd exactly why you insist in the inheritable part; isn't
the same if it were not inheritable? Maybe I don't get your main concerns
correctly...)

--
Gabriel Genellina