A design problem I met again and again.

一首诗 newptcai at gmail.com
Wed Apr 1 03:44:01 EDT 2009


Hi all,

I am a programmer who works with some different kinds of programming
languages, like python, C++(in COM), action script, C#, etc.

Today, I realized that, what ever language I use, I always meet a same
problem and I think I never solve it very well.

The problem is : how to break my app into functional pieces?

I know it's important to break an application to lots of pieces to
make it flexible.   But it's easier said than done.     I can split an
application to 4 or 5 pieces based on "programming functions", for
example,  logging,  socket, string,  math, ...

When it comes to the business logic,  I found I always provide a big
class with many methods, and it grow bigger when new functions are
added.

Recently I use twisted to write a server.   It has several protocol
classes which decode and encode different kinds of network protocols ,
and a protocol independent service class which handle request from
clients according to business logic.

Protocol classes receive message from client, decode it, call method
of service, encode result and send it back to client.

There are also some utility packages such as logging as I mentioned
before.

So far so fine,  every thing is clear.

Until one day I find service has nearly 100 methods and 6000 lines of
code.   I don't need to read any programming book to know that it's
too big.

But I can not find an easier way to split it.  Here are some
solutions  I found:

1. add several business classes, and move code in service into them.
But this means although service will contains much less code, it still
has to keep lots of methods,  and the only functions of these methods
is call corresponding methods in business classes.   The number of
methods in service will keep growing for ever.

2. completely move codes in service to business classes containing
only classmethods.  These protocol classes calls these classmethods
directly instead of call service.   But this pattern doesn't look that
OO.

3. completely move codes in service to business classes.  Initialize
these classes and pass them to protocol classes.
These protocol classes calls these instances of business classes
instead of call service.  These means whenever I add a new business
class.  I have to add a parameter to __init__ methods of every
protocol class.  Not very clear either.

==========================================

I got the same problem when writing C#/C++ when I have to provide a
lot of method to my code's user.  So I create a big class as the entry
point of my code.  Although these big classes doesn't contains much
logic,  they do grow bigger and bigger.



More information about the Python-list mailing list