api connection class design

What I currently have and request a suggestion to modularize it

public sealed class Connection: BaseConnection{

//I have to process about 30 events
public event Handler1=handler1;
public event Handler2=handler2;
public event Handler3=handler3;
public event Handler4=handler4;

//I have to process about 30 service calls

public void Service1(){}
public void Service2(){}
public void Service3(){}

private void OnHandler1(Request aRequest)
{
if (handler1 != null)
handler1(aRequest);
}

private void OnHandler2(Request aRequest)
{
if (handler2 != null)
handler2(aRequest);
}

private void onHandler3(Request aRequest)
{
if (handler3 != null)
handler3(aRequest);
}

//and so on
protected override Dispatch(Event e){ // based on event, I
process
and call onHandlers}

// more functions to process the events.

}

In separate file, I define all those delegates. I give client the dll
containing this class and some enumerations, and declarations.

So, the client of my api would use it in this way

Connection conn=new Connection();
conn.handler1+=...
conn.handler2+=...
//etc
conn.Connect();
conn.Service1();
conn.Listen();
conn.Destroy();

The issue is that I implement services and event handling in just one
class Connection, taking some implementation from Base connection,
resulting in over 4K lines of code. Any suggestion to improve the
design?

Thanks

puzzlecracker <ironsel2000@gmail.com> writes:
> What I currently have and request a suggestion to modularize it
[ . . . ]
> //I have to process about 30 events
[ . . . ]
> //I have to process about 30 service calls
>
> public void Service1(){}
> public void Service2(){}
> public void Service3(){}
>
> private void OnHandler1(Request aRequest)
[ . . . ]
> private void OnHandler2(Request aRequest)
[ . . . ]
> private void onHandler3(Request aRequest)
[ . . . ]
> The issue is that I implement services and event handling in just
> one class Connection, taking some implementation from Base
> connection, resulting in over 4K lines of code. Any suggestion to
> improve the design?

This may not be exactly what you need, but I wrote an example of
something similar using the Chain of Responsibility pattern as part of
a discussion here a few years ago. Assuming bit rot hasn't set in,
the code should still work:

http://www.spe.com/Chain_of_Responsibility.html

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Responding to puzzlecracker...

> So, the client of my api would use it in this way
>
> Connection conn=new Connection();
> conn.handler1+=...
> conn.handler2+=...
> //etc
> conn.Connect();
> conn.Service1();
> conn.Listen();
> conn.Destroy();
>
> The issue is that I implement services and event handling in just one
> class Connection, taking some implementation from Base connection,
> resulting in over 4K lines of code. Any suggestion to improve the
> design?

The interface is fine; the problem is in its implementation.

What you seem to be defining is a GoF Facade pattern. Connection
provides the interface the client needs to access various services. But
there is no rule that says those services need to be implemented in a
single class.

You are essentially creating a subsystem here around the subject matter
of providing services. Abstract that subject matter as a standalone
solution with appropriate objects. Then provide Connection as the
subsystem interface. (Note that Connection and the subsystem objects can
still be packaged in a DLL for the client so that only Connection's
interface is visible; in effect the DLL is the subsystem.)

You have already described at least four different design
responsibilities: keeping track of callbacks; establishing/removing
links to various services; providing specific services; and some kind of
monitoring of services (via Listen). Those are all potentially complex
issues that are related under the general umbrella of providing a
specific suite services. Treat resolving all those things as part of the
unique problem of providing the services. Then solve it by isolating and
encapsulating those responsibilities in appropriate objects that
abstract the invariants of that subject matter. Once you know how to
manage the services, let Connection dispatch to them.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH