An Enterprise service bus is a cool piece of technology designed to solve a specific problem. Basically, it’s and N to N multicast communication device. You can have a variable number of message senders and a variable number of message recipients. Decoupling the senders and receivers and decreasing the number of touch points in inter-service communication.

The downside of an enterprise service bus solution is that you need to make sure you have an ESB type problem. Like a lot of enterprise patterns such as CQRS, an ESB is great at solving it’s specific type of problem and truly horrible when it’s not applied to the right problem.

Read the rest of this entry »

The SOLID principles have been kind of a cornerstone in software development for me. I think if the SOLID principles as part of the foundation of what makes good software. I kind of wonder about the fad for using closures now. Maybe I’m just an old crusty developer doing the equivalent of “you kids get off my lawn!” but it seems like closures are just another way of doing function pointers that made working in C/C++ such a pain in the butt.

This article http://arstechnica.com/information-technology/2012/09/should-i-continue-teaching-myself-how-to-code-or-should-i-go-pro/ started me thinking about closures in a different way. In a lot of ways a closure is all about inversion of control. They’re about passing around the logic to work on various sets of data. That’s pretty much the definition of inversion of control.

Although, I will admit that I’m not the greatest fan of the C# style of anonymous closures. I think that they tend to be over used, like all fashions. They have they’re place, but that place isn’t every place.

I think the case against closures is really about the Law of Demeter, the D in SOLID. The way that the law of demeter works is basically the transitive property of objects.  “The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).”

Closures, particularly anonymous closures that access variables outside of their lexical scope increase the brittleness of software by breaking the law of Demeter, just for variables instead of objects. By creating super complex closures, we lose sight of what’s defined where and it’s easy to create errors that flat out wouldn’t happen with named closures instead. If you’re in C#, this is no big deal you get a compile error, but it adds hours of debugging time in an interpreted language like javascript. Basically, the closure function is making assumptions about what is defined in the outer lexical scope(s).

In the end, I think that the SOLID principles are still the fundamentals and should be followed as a default.  Although, we should keep in mind other ideas, like closures that can help when appropriate.  “Rules exist to make you think before you break them.”