Emmanuel Lecharny wrote: > "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote >>> The differences between IoHandler and IoFilter are: >>> >>> * IoHandler doesn't have life cycle callbacks (onPreAdd, >>> onPostRemove...) while IoFilter has. >>> * IoHandler doesn't have handler methods for requests such as write, >>> setTrafficMask and close while IoFilter has. >>> >>> This is why I'm proposing to split IoFilter into multiple interfaces: >>> >>> * Interface A which provides handler methods for incoming events. >>> * Interface B which extends the interface A and provides handler methods >>> for outgoing requests >>> * Interface C which extends the interface B and provides lifecycle >>> management methods >>> >>> This inheritance relationship might not be precise. For example, both >>> interface B and C could extend the interface A directly. >>> >> >> UpstreamFilter and DownstreamFilter sounds somewhat strange. :) >> >> What about InputHandler, OutputHandler, IoHandler (extends InputHandler >> and OutputHandler) and LifecycleAwareHandler? >> >> > Just a quick Q : do we really need those three interfaces ? > > For instance, A and B can be merged, as I don't know a lot of protocol > who deal with incoming requests but never send back a reply (of course, > there are some, but it's not the general case). If you don't have any > outgoing requests, then an abstract class can implement a null operation > for outgoing requests.
Current IoHandler probably doesn't need to handle outgoing request? They could just leave unused methods empty. :) Once IoFilter replaces IoHandler, even the last handler will be invoked with NextFilter (or NextHandler if renamed). Which is somewhat less optimal. We can take care of this by providing an abstract class of course. How does it sound? > > The very same for C, I see no reason why we should not merge it with A > and B. > > In any case, if you have an inheritance scheme like A <-- B <-- C (<-- = > extends), then I think we can merge those three interfaces, except if > implementing a specific interface will bring some specific function. > > A class which will need to implement A and C for instance would be > better described as class MyClass implements A,C instead of having an > inheritence between C, B and A. > > What I mean is that interfaces might not inherits from each other, if > they are just extending the API. > > Here, if we don't merge the interface, something like : > > class UpstreamFilter implements A > > class DownStreamFilter implements B > > class ManagedUpstreamFilter implements A,C > > class ManagedDownStreamFilter implements B,C > > class ManagedFullFilter implements A,B,C > > covers all the case. > > About the names, keep Filter. Handler has a different semantic to me... > (may be it's just me) Yep. I agree with you having all these types doesn't look that clean. Maybe we could just replace IoHandler with IoFilter meanwhile and see what users think. -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
