In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

On NetTuts.com today they've continued their series covering the SOLID development principles with the next letter in the acronym - "L". It stands for the Liskov Substitution & Interface Segregation Principles. The tutorial also talks some about the "Interface Segregation Principle" as they go hand-in-hand.

The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows: "Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T." [or more simply] "Subtypes must be substitutable for their base types."

They include some example PHP code showing a base "Vehicle" class and first an example of doing it correctly (with the Template design pattern) and an example of an incorrect method, complete with tests. They then get into the Interface Segregation Principle, an interface that can be depended on to use the module, with the same car-related examples.