what I need is a pattern to resolve the problem (maybe it's not a problem), it's a part of a project, it's dependent of any platform.
the customer has specification, but don't care about it, you can implement it in the derived class, it's not related with the pattern, I guess you didn't read books about design pattern

本文发表在 rolia.net 枫下论坛1). If we assume that the clients are the same, the increase of client numbers cannot be the reason to modify the code. If the clients can be classified into come classes,
one may need to modify the code or configure the whole system. This is why I stress one must distinguish one client from one class of clients. Without business context, it is pointless to talk about patterns.

2)If the clients are almost the same and they enjoy the service provided by the server, one can use connection pooling, which is already a pattern. In JDBC and EJB, connection pooling technology provides some scalability. However, any server (DB, EJB...) has an upper limit in serving the clients.

3) If the clients can be classified, I still suggest using Adapter and Facade patterns.
Whenever a new class of clients come about,
one can add a new Adapter for them WITHOUT modifying the original code. With the help of Facade pattern, one can output service by adding one or two static methods.
It sounds trivial, but it may solve the problem to some extent. Adding some code is better than modifying the original code.

4) As we talk about the pattern, we should ask: Does the same thing occur REPEATEDLY in the life? One cannot claim a pattern simply because he/she meets a new issue. In addition, the life (or the project) is complicated, behind some seemingly simple fact are a bunch of patterns co-operating with each other.

5) Some time earlier, Marco posted his experiences in a VC++ project. In that project, the system did not work well as the client population reaches 800. Obviously, such system limitation cannot be cured by using some patterns.

6) Indeed, patterns are an advanced topic for programmers. If one does know patterns, or has not yet read the book by Gang of Four(GOF), he/she does not need to be discouraged. (Honestly speaking, I have not yet got the chance to lokk into the Gang Of Four book. Probably, I won't read it in the future.) If one is a pattern guru like Mark Grand, he/she does not show off before the peer. My client has a system architect who cannot code in C++, but nobody can deny his string perspective in the system architecture.

7) If something is pushed to extremities, things may not go on as expected. For instance, we know that methodology is very important for OOP. If one sticks to the philosophy of three Amigos, the project may fall into the analysis paralysis. Likely, if one insists fitting into some patterns in each aspect of a project, things can become fanny.

8)Having reading some famous books does not mean being a guru. Aconcoction of pattern cannot yield a robust project. If one cannot make himsel/herself understood, he cannot undertake the task of being an architect.
This is why I have ever said that few Chinese guys can play a role of architect. Being an archiect, one should be able to communicate with novices, laymen using everyday English. If the partner does not understand, one should try to get him/her accrossed using examples.

9) Just like Marco, I have nothing more to say.
Marco told me that many developers in Canada have read the GOF book. What I realize is that some developers I know are abusing patterns, or using patterns for pattern's sake.更多精彩文章及讨论，请光临枫下论坛 rolia.net