Ayende @ Rahien

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

Wed, 15 Feb 2012 22:24:32 GMT

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 commented on Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

Wed, 15 Feb 2012 21:36:52 GMT

Ilyys, who calls those methods?

Stephen Shen commented on Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

Fri, 10 Feb 2012 02:29:07 GMT

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?

Ayende Rahien commented on Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

Thu, 09 Feb 2012 18:48:27 GMT

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); } }

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

Thu, 09 Feb 2012 18:42:46 GMT

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.

Sony Mathew commented on Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

Thu, 09 Feb 2012 15:44:51 GMT

Argh...my generics where stripped out..

Sony Mathew commented on Limit your abstractions: Application Events–Proposed Solution #2–Cohesion

Thu, 09 Feb 2012 15:35:45 GMT

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) {
    ...
  }
}

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

Thu, 09 Feb 2012 15:17:55 GMT

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.