ShapeShifting Interfaces

I would like to propose a new way of thinking about the ubiquitous software “contract”.

Sign Here please

You and I to a lesser or greater extent design and/or implement interfaces in most software activities. We create them knowingly and some times as an affect of or in consequence of writing within an environment. For example, you can use C#, to create some object, which is now “contracted” to System.Object and then you extend that interface with more members, until you have something you start using within a client/consumer which subscribes to that “contract”. This is our world.
From COM, to SOA, we talk about contracts and implement interfaces and we do this because this is how our world works.

An analogy of some sort:
Sidepoint: In OO, people like using the noun/verb analogy (and some don’t), however I always use it in a 101 lesson, as it is a good starting point. It does ring true on many levels. I will use it here as a simple example of a Person named John, and his fingers.

John has 5 fingers. At the time of writing this I used his 5 fingers to construct a diagram of where to wear your rings. I sent the diagram to 10 people, and shortly thereafter, (tragically I might add), John lost 2 of his fingers in a software related incident.
Our diagram is ruined. It is out of date. However we can solve this in a few ways.
We can name the hand “Jane”, and she has 5 fingers. Or we name it John2.
Now we can happily go on, until John2 has an accident, hitting a Design Pattern head-on, and loses his thumb in the process. John3 now born into this shoddy growing dilemma, has little choice about happiness, he has 2 fingers left and none of the diagrams are accurate any longer.

My diagram was and is always bound by contract to these people.

You have to Pay to "Break the Contract"

The problem here is how we continuously treat consumers of our classes.
We treat consumers as being stupid and pretty ineffective at knowing what to do, should we not have an interface it expects. I think that this is actually a problem to be solved, not a design limitation on the object it uses.

In the beginning, John has 4 fingers and a thumb; we know that he loses two fingers and a thumb. In human terms we could attach a note to the diagram which specifies the fact that the middle and index finger is actually missing, and as a human consumer of that diagram, we would now know the facts.

Then further, there is the consequence of John losing the fingers in the relationship between consumer and class.
Sometimes, it would not matter, because we were always looking at the thumb and sometimes it would matter completely as all we were requiring were the very two fingers that are now missing. In software though, one slight change to a class may kill everything.

So there is my small silly overview of the large problem we actually have.

Contractually Speaking

We create interfaces and contracts in IDL, WSDL and so on, but never really think about how to design “changing interfaces”. We create database schemas, xml standards, and everythign we do is FIXED. How can we speak of contracts and then break them all the time.
For example: Refactoring is an agile activity but it is in conflict with contracts. You always have to be careful.

How can software move forward if we cannot even change something as simple as an Interface that was designed a consumer ago.
We need to work on Interfaces that can bend. I don’t mean breaking interfaces, but rather changing slightly to suit a new set of requirements.

Interfaces are too rigid, they need to be able to change. Our existing software languages and models, do not allow us to make things agile enough and it cannot support changing interfaces inherently.

Let the Courts decide

Our contract has changed? Is that a bad thing? Should we pay for it?

When “Consumer A” looks at the same Interface, it should see a different interface than “Consumer B” sees, and we should be able to control it absolutely, without creating new classes, facades, proxies and agents like we have to do today.

We need a much larger evolving and mature look at "interface scope and control".

Our Interfaces should be capable of ShapeShifting and the contracts should be allowed to change, albeit with boundaries.
When this occurs in our toolsets, I am sure we will be able to make more elegant and agile solutions.
Obviously, the power of shapeshifting must be controlled, abd if it got into the wrong hands, could be used for evil. But I think that in all steps forward comes sacrifice.

[If you have an opinion on ShapeShifting Interfaces, send me an email and I would be happy to post your comments here]