Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

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:

container.executeall<ihappenon<cargo>>(i=>i.inspect(cargo));

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)
      return;
      
    // handle event
  }
}

public class cargomisdirected : ihappenedon<cargo>
{
  public void inspect(cargo cargo)
  {
    if(cargo.delivery.misdirected == false)
      return;
      
    // 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)
  {
    if(cargo.delivery.unloadedatdestination)
      cargoarrived(cargo);
      
    
    if(cargo.delivery.misdirected)
      cargomisdirected(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.