Limit your abstractionsApplication 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.
More posts in "Limit your abstractions" series:
- (22 Feb 2012) And how do you handle testing?
- (21 Feb 2012) The key is in the infrastructure…
- (20 Feb 2012) Refactoring toward reduced abstractions
- (16 Feb 2012) So what is the whole big deal about?
- (15 Feb 2012) All cookies looks the same to the cookie cutter
- (14 Feb 2012) Commands vs. Tasks, did you forget the workflow?
- (13 Feb 2012) You only get six to a dozen in the entire app
- (10 Feb 2012) Application Events–event processing and RX
- (09 Feb 2012) Application Events–Proposed Solution #2–Cohesion
- (07 Feb 2012) Application Events–Proposed Solution #1
- (06 Feb 2012) Application Events–what about change?
- (03 Feb 2012) Application Events–the wrong way
- (02 Feb 2012) Analyzing a DDD application
Comments
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.
Tried to post this on your previous post but looks like it didn't succeed.
IHappenOn<T> amounts to the mediated Event/Listener or Observer pattern e.g. Observer<T> or Listener<T> or even Processor<T> mediated by a central Mediator. Unfortunately in Java (not sure about C#) using Generics gets in the way because implementations generally implement multiple Listener<T> 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:
Argh...my generics <T> 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.
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); } }
This is very cool. I like the extension method. I am wondering do we really need generic T abstraction in the IHappenedOn<T>?
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<T> for Cargo, and Apple?
Shall we limit this sort of abstraction?
Ilyys, who calls those methods?
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;
}
}
Comment preview