good name to dispatch events (naming convention)

public delegate MessageHandler(Request request)

public sealed class Connection{


public event MessageHandler handler;


private void ExecuteMassageHandler(Request request)
{
if(handler!=null)
handler(request);
}
}


What's a good name, perhaps conventional, used in the place of
ExecuteMassageHandler?

Thanks

> What's a good name, perhaps conventional, used in the place of
> ExecuteMassageHandler?

Uh, HandleMessage?

(The convention is class names and objects are nouns, and method names are
predicates starting with verbs.)

BTW you may want to look "massage" up in a dictionary. (-:

Responding to puzzlecracker...

> public delegate MessageHandler(Request request)
>
> public sealed class Connection{
>
>
> public event MessageHandler handler;
>
>
> private void ExecuteMassageHandler(Request request)
> {
> if(handler!=null)
> handler(request);
> }
> }
>
>
> What's a good name, perhaps conventional, used in the place of
> ExecuteMassageHandler?

It depends on what the responsibility is.

Is ExecuteMessageHandler an exception handler? Then messageHandler is
probably a good name. But "Handler" has semantic baggage from exception
processing so it is probably not a good idea to use it in other contexts.

Is ExecuteMessageHandler solely to provide a callback for someone else
to process the message? Then the name wants to reflect the
responsibility of re-dispatching since that is what the responsibility
is about (e.g., invokeClientMessageProcessor). Even then there could be
a lot of variation; you need to use a name that mostly clearly
represents what is important about the responsibility in the problem
context.

Given the callback registration you have already described, the name you
might want to revise is more likely to be "handler". That is, it is
really the handler that provides the semantics of the callback (i.e., it
is hook to specific external processing). So your Connection method
might be:

private void processRequest (Request request)
{
if (externalMessageProcessor != NULL)
externalMessageProcessor (request);
}

Presumably any client of Connection does not care about the callback
semantics, it just wants a Request processed. So from its perspective it
thinks Connection's responsibility is to process its request. OTOH, in
the implementation of the responsibility, one cares a very great deal
about the callback mechanism and one should have a meaningful name for
the callback with respect to the external processing.


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

Phlip wrote:
>> What's a good name, perhaps conventional, used in the place of
>> ExecuteMassageHandler?
>
> Uh, HandleMessage?
>
> (The convention is class names and objects are nouns, and method names
> are predicates starting with verbs.)
>
> BTW you may want to look "massage" up in a dictionary. (-:
Or the phone-book, depending on how stressful you find dictionaries.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

On Oct 5, 10:20*pm, Phlip <phlip2...@gmail.com> wrote:
> > What's a good name, perhaps conventional, used *in the place of
> > ExecuteMassageHandler?
>
> Uh, HandleMessage?
>
> (The convention is class names and objects are nouns, and method names are
> predicates starting with verbs.)
>
> BTW you may want to look "massage" up in a dictionary. (-:

I don't think it's going to work since i have difference signatures:

public delegate onMessageHandler(string request);
public delegate onLoginHandler(string username, string password );
public delegate onSendRequestHandler(string request, ind id);

//etc

public sealed class Connection{

public event onMessageHandler onMessage;
public event onLoginHandler onLogin;
public event onSendRequestHandler onSendRequest;

private void ExecuteOnMessage(string request)
{
if(onMessage!=null)
onMessage(request);
}
private void ExecuteOnLogin(string username, string password)
{
if(onLogin!=null)
onLogin(username, password);
}
private void ExecuteOnSendRequest(string request, int id)
{
if( onSendRequest!=null)
onSendRequest(request, id);
}
}

"puzzlecracker" wrote:
>
> public delegate MessageHandler(Request request)
>
> public sealed class Connection{
>
>
> public event MessageHandler handler;
>
>
> private void ExecuteMassageHandler(Request request)
> {
> if(handler!=null)
> handler(request);
> }
> }
>
>
> What's a good name, perhaps conventional, used in the place of
> ExecuteMassageHandler?

You're using C#, right? Look up the event guidelines on MSDN.

Typically, you declare the delegate with the name XXXHandler. This delegate
usually takes two arguments: One of type object representing the object
responsible for raising the event, and two an object derived from the
EventArgs (or one of its descendants) class. The method that raising the
event it typically protected virtual and has the name OnXXX.

An example:

public delegate void SampleRateChangedHandler(object sender,
SampleRateChangedEventArgs e);

public class Widget
{
public event SampleRateHandler SampleRateChanged;

protected virtual void OnSampleRateChanged(SampleRateChangedEventArgs e)
{
SampleRateChangedHandler handler = SampleRateChanged;

if(handler != null)
{
handler(this, e);
}
}
}

puzzlecracker <ironsel2000@gmail.com> writes:
> I don't think it's going to work since i have difference signatures:
>
> public delegate onMessageHandler(string request);
> public delegate onLoginHandler(string username, string password );
> public delegate onSendRequestHandler(string request, ind id);
>
> //etc
>
> public sealed class Connection{
>
> public event onMessageHandler onMessage;
> public event onLoginHandler onLogin;
> public event onSendRequestHandler onSendRequest;
>
> private void ExecuteOnMessage(string request)
> {
> if(onMessage!=null)
> onMessage(request);
> }
> private void ExecuteOnLogin(string username, string password)
> {
> if(onLogin!=null)
> onLogin(username, password);
> }
> private void ExecuteOnSendRequest(string request, int id)
> {
> if( onSendRequest!=null)
> onSendRequest(request, id);
> }
> }

This design violates the Open/Closed Principle. Whenever you add
a new event type, you'll have to modify Connection. You have a couple
of options. The first is to move the behavior from whatever calls
Connection to the events and replace your handler methods with a
generic handler:

private void processRequest(Request request)
{
request.execute();
}

Another alternative is to use the Chain of Responsibility pattern
to add behavior dynamically while keeping the event classes relatively
simple.

There are other alternatives as well, all of which revolve around
decoupling generation of events from routing events from processing
events. If you start by not violating the OPC, you'll get to a more
robust design.

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)

As mentioned before, Connection class handles the requests from
clients, sends them over to some broker, and then dispatches results/
acks to clients .


> This design violates the Open/Closed Principle. Whenever you add
> a new event type, you'll have to modify Connection. You have a couple
> of options. The first is to move the behavior from whatever calls
> Connection to the events and replace your handler methods with a
> generic handler:
>
> private void processRequest(Request reest)
> {
> request.execute();
> }

I dont have a generic type request for my delegates. Events have
different signatures, sometimes comprised of built-in types, that are
read off socket. Perhaps, I am not understanding your suggestion
here.

> Another alternative is to use the Chain of Responsibility pattern
> to add behavior dynamically while keeping the event classes relatively
> simple.

I don't see how the chain of responsibility pattern can be used
here, without making the design more complex and harder to expand. I
basically have one event type per each client service call. Hence
client subscribes to events, calls one of the services, and waits for
results

client
----------

Connection conn =Connection.GetInstance();
conn.OnMessage+=SomeImplHandler;
conn.OnMessage+=SomeImpl2Handler;
conn.CallService();
conn.CallService2();

conn.Wait(); // reads results of the socket and calls handlers (those
2 methods will be called)

public static void SomeImplHandler(sting hello){

}

public static void SomeImpl2Handler(strng u , string pass){

}


I just don't see where to plug in the chain of responsibility.

> There are other alternatives as well, all of which revolve around
> decoupling generation of events from routing events from processing
> events. If you start by not violating the OPC, you'll get to a more
> robust design.

Would you elaborate on this alternative please or send links with
information?

Thanks

puzzlecracker <ironsel2000@gmail.com> wrote:

> public delegate MessageHandler(Request request)
>
> public sealed class Connection{
>
>
> public event MessageHandler handler;
>
>
> private void ExecuteMassageHandler(Request request)
> {
> if(handler!=null)
> handler(request);
> }
> }
>
>
> What's a good name, perhaps conventional, used in the place of
> ExecuteMassageHandler?

Why is the method being called? That should suggest a good name.

Remember, your supposed to be sending messages to objects, not commands,
not orders, but messages.

puzzlecracker <ironsel2000@gmail.com> writes:
> As mentioned before, Connection class handles the requests from
> clients, sends them over to some broker, and then dispatches results/
> acks to clients .

Thanks for the clarification. If I understand correctly, then, an
instance of the Connection class is instantiated on the server for each
socket connection?

>> This design violates the Open/Closed Principle. Whenever you
>> add a new event type, you'll have to modify Connection. You have a
>> couple of options. The first is to move the behavior from whatever
>> calls Connection to the events and replace your handler methods with
>> a generic handler:
>>
>> private void processRequest(Request reest)
>> {
>> request.execute();
>> }
>
> I dont have a generic type request for my delegates. Events have
> different signatures, sometimes comprised of built-in types, that are
> read off socket. Perhaps, I am not understanding your suggestion
> here.

It was me not having a full understanding of your design. To be
clear, what you're reading off the socket is a stream consisting of the
event type followed by any required parameters?

>> Another alternative is to use the Chain of Responsibility
>> pattern to add behavior dynamically while keeping the event classes
>> relatively simple.
>
> I don't see how the chain of responsibility pattern can be used here,
> without making the design more complex and harder to expand. I
> basically have one event type per each client service call. Hence
> client subscribes to events, calls one of the services, and waits for
> results

Assuming I've understood your design correctly, Chain of
Responsibility can be used similarly to how I implemented it here:
http://www.spe.com/Chain_of_Responsibility.html. In your particular
case, the Connection class would be responsible for managing the
socket. When new data arrives, the Connection class reads the event
type and passes it and the socket connection to a chain of handlers.
The handler for that type accepts responsibility and uses the socket
connection to read any additional data required. (Adding a default
error handler to the chain is a good idea.)

Handlers can be added and removed at any time. Either the
Connection class or a shared HandlerChain class can maintain the list.
The interface for the chain consists of three or four methods:
handleEvent, registerHandler, unregisterHandler, and possibly
updateHandler.

The Handler interface, implemented by all event handlers, exposes
only a handleEvent(Event,Socket) method.

This approach makes the system open for extension but closed to
modification, as recommended by the Open-Closed Principle. Each class
has one well-defined responsibility and new functionality can be easily
added without impacting existing, working, tested code.

Will this work in your environment?

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)