Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,550

filter by tags archive

Limit your abstractionsApplication Events–Proposed Solution #2–Cohesion

time to read 4 min | 713 words

In my previous post, I spoke about ISP and how we can replace the following code with something that is easier to follow:


I proposed something like:

public interface IHappenOn<T>
   void Inspect(T item);

Which would be invoked using:


Or something like that.

Which lead us to the following code:

public class CargoArrived : IHappenedOn<Cargo>
  public void Inspect(Cargo cargo)
    if(cargo.Delivery.UnloadedAtDestination == false)
    // handle event

public class CargoMisdirected : IHappenedOn<Cargo>
  public void Inspect(Cargo cargo)
    if(cargo.Delivery.Misdirected == false)
    // handle event

public class CargoHandled : IHappenOn<HandlingEvent>
   // etc

public class EventRegistrationAttempt : IHappenedOn<HandlingEventRegistrationAttempt>
  // etc

But I don’t really like this code, to be perfectly frank. It seems to me like there isn’t really a good reason why CargoArrived and CargoMisdirected are located in different classes. It is likely that there is going to be a lot of commonalities between the different types of handling events on cargo. We might as well merge them together for now, giving us:

public class CargoHappened : IHappenedOn<Cargo>
  public void Inspect(Cargo cargo)
  public void CargoArrived(Cargo cargo)
    // handle event
  public void CargoMisdirected(Cargo cargo)
    //handle event

This code put a lot of the cargo handling in one place, making it easier to follow and understand. At the same time, the architecture gives us the option to split it to different classes at any time. We aren’t going to end up with a God class for Cargo handling. But as long as it make sense, we can keep them together.

I like this style of event processing, but we can probably do better job at if if we actually used event processing semantics here. I’ll discuss that in my next post.

More posts in "Limit your abstractions" series:

  1. (22 Feb 2012) And how do you handle testing?
  2. (21 Feb 2012) The key is in the infrastructure…
  3. (20 Feb 2012) Refactoring toward reduced abstractions
  4. (16 Feb 2012) So what is the whole big deal about?
  5. (15 Feb 2012) All cookies looks the same to the cookie cutter
  6. (14 Feb 2012) Commands vs. Tasks, did you forget the workflow?
  7. (13 Feb 2012) You only get six to a dozen in the entire app
  8. (10 Feb 2012) Application Events–event processing and RX
  9. (09 Feb 2012) Application Events–Proposed Solution #2–Cohesion
  10. (07 Feb 2012) Application Events–Proposed Solution #1
  11. (06 Feb 2012) Application Events–what about change?
  12. (03 Feb 2012) Application Events–the wrong way
  13. (02 Feb 2012) Analyzing a DDD application



Much easier to understand! What we need to remember is while some of us may be rock stars when it comes to coding, junior developers (or noobs) are not. As much as you "want"/"push" them to learn these higher level concepts it doesn't happen. Keeping code simple goes a long way in my opinion.

Sony Mathew

Tried to post this on your previous post but looks like it didn't succeed.

IHappenOn amounts to the mediated Event/Listener or Observer pattern e.g. Observer or Listener or even Processor mediated by a central Mediator. Unfortunately in Java (not sure about C#) using Generics gets in the way because implementations generally implement multiple Listener and Java Type erasure will cause a compile failure. Hence the approach I took with Event classes inlining their Mediator, Listener and optionally Processor interfaces as shown in my pasted code from a few posts ago:

class CargoDeliveryStatusEvent extends Event {
  interface Mediator {  
    void fire(CargoDeliveryStatusEvent e);
    void register(Listener l);
  interface Listener {
    void handle(CargoDeliveryStatusEvent e);
  CargoDeliveryStatusEvent(Cargo.DeliveryStatus deliveryStatus) {
Sony Mathew

Argh...my generics where stripped out..


I'd be curious to see container.ExecuteAll, unless this is a new feature in Windsor 3 that I've totally overlooked somehow or something like that. This precise scenario is something that comes up a lot in my apps and I am always curious to see how different people implement it.

Ayende Rahien

Shawn, It is an extension method:

public static void ExecuteAll{T}(this IKernel kernel, Action{T} action) { foreach(var item in kernel.ResolveAll{T}) { action(item); } }

Stephen Shen

This is very cool. I like the extension method. I am wondering do we really need generic T abstraction in the IHappenedOn?

Will this interface be used to inspect another type other than Cargo? Say yes if in another context, shall we do another specific interface eg IHappendOnCargo, & IHappendedOnApple, vs IHappenedOn for Cargo, and Apple?

Shall we limit this sort of abstraction?


Why add another event abstraction for executing simple business logic?

If you could just add some simple entity logic directly on to the entity. And invoke entity method "manually" by executing method when something happens.

For example

class Cargo{ public virtual string DeliveryStatus {get;set;} public virtual Delivery Delivery {get;set;} ... #region business logic public void onCargoArrived(){ DeliveryStatus=DeliveryStatus.Ready; }

public void onCargoMisdirected(){ DeliveryStatus=DeliveryStatus.Misdirected; CargoRecievedDate=null;


Ayende Rahien

Ilyys, who calls those methods?

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - about one day from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats