Thoughts On ...

Interfaces with small i's

In reading the interesting discussion between Julian Birch and Ryan Svihla here, here and here on Bob Martin's SOLID principles in dynamic languages. I had many thoughts; variously agreeing and disagreeing with what I was reading, till eventually I realized that I couldn't characterize my take on the discussion in those terms. Rather, I felt like Julian and Ryan were using a different language than me that happened to use the same words.

So I decided to explore the idea myself to see if I could get at why I feel that way. I'm going to focus on only one of the SOLID principles they discuss: ISP or Interface Segregation Principle as they discuss it quite a bit (if this SOLID stuff is new to you take a couple seconds to read Bob's definition then come back... OK? Moving on...).

Here's a summary of Julian and Ryan's take on the ISP in dynamic languages:

Ryan:

Ryan seems to see ISP as an implementation design tool that we apply when programming - at least in non-dynamic languages, because we get 'it' for free in dynamic languages - to better understand our code and reduce our work in implementing Interfaces (note the big 'I').

Julian seems to agree in that ISP is something that we can't avoid doing (for better or worse) in dynamic languages:

Julian:

Now, one thing that struck me is that neither of them described the problem. SOLID (and so ISP) are design principles, so presumably there is a design problem that we're trying to avoid by adhering to it. Julian and Ryan seem very familiar with SOLID so I assume that's why they leave it unstated (though Ryan implies that its related to defining and understand interfaces), but I think its key to understanding why I feel we have different understandings of ISP's applicability.

So let's look at what Bob says the problem is (from the Engineering Notebook article linked to above):

Get that? According to Bob we are trying to reduce "spooky action at a distance" type dependency problems in our code-base. If ISP does this, then according to Ryan and Julian when I work in Ruby (as I am now) I should not have code dependency issues related to multiple clients using the same code (as I did when writing C++ or C# code) because each client inherently gets its own custom interface via the magic of duck typing.

I.e.: Duck Typing makes it unnecessary and even unmeaningful to think about ISP when writing code in dynamic languages as we get its benefits (easier to understand and maintain interfaces) for free.

Now, I'm pretty sure I disagree with this and for two reasons: 1) Nowhere is it established that we get the true benefit of ISP - dependency management - for free, and 2) I'm not convinced duck typing absolves me of having to worry about how multiple clients interact with a single piece of code.

[this is going to take longer than one blog entry to explore, so I may return to these two items in follow-on posts]

But in a larger sense I think the fundamental disconnect lies in how I view the importance of the (necessary) context of Uncle Bob's examples. OO and these principles evolved in statically typed languages, so the thinking about how to apply them evolved that way too. As such, Interfaces (i.e. language constructs) are used in examples and solutions and testing via them has over the past 10 years become the most concrete way of showing improvement.

However, I believe that ISP doesn't only apply to Interfaces as language constructs, but also to interfaces as definitions of interaction. If I'm correct than ISP is applicable not only to Big 'I' Interfaces, but also to public method definitions, protocols, even data interchange, schemas and log files.

And this makes sense if you recall that in the SOLID article Bob starts out talking about Structured Programming and OO - and why those two movements began in the first place: to manage code growth. Code written in dynamic languages has to manage these forces as well. That they take on different character is not to say the principles no longer apply, but that the implementation patterns don't. Perhaps in the end that's really what I disagree with, for both Ryan and Julian seem to be saying something like dyamic languages have their own dependency issues (Ryan proposes SELL for example) but I don't see ISP as an implementation tool, its a way of thinking about code. And this I believe is the heart of the disconnect. So I'll stop there for now.

In short: The ISP means that we as software designers think about segregating client demands on our code as those demands shear in different directions lest we find ourselves in situations where changes to meet one demand negatively impact the quality of solutions to other demands. This type of thinking is needed in dynamic languages as well as in static languages, though the manifestation of problem and solution may look very different. I plan to follow this with additional posts to dive into the distinction.