What is the best analogy to help non-oop developer

Question

I'm having a hard time trying to get my team comfortable with interface based programming ... anyone have some suggestions?

Answer 1

Another way I've used succesfully when teaching new junior hires in our company is considering an interface as "a way of looking at an object", literally.

Analog: take a 3D object, like a piece of tube. Depending on which direction you look at it, it looks like ("behaves as") either a circle, a rectangle or a 3D object. The concept of casting can then easily be equated to "try to rotate the object so you can make it look the way you want/need" which either succeeds or fails depending on the object and the view you're looking for.

The analog isn't really 100%, but it can help to make something that is very abstract for people not already grasping the concept into something concrete.

Answer 2

In order to help your team get comfortable with the idea, the best route would be to demonstrate what interface-based development can accomplish and contrast that with how the same thing would need to be done without it. For them to "really" accept and begin to understand it, they first need to understand and feel the pain of the problem that it solves. They really need to have the "I'm sick and tired of having to do X every time that Y happens" conversation with themselves or the team. One thing that my father drilled into me in my "formative" years is this little gem:

No matter how many times it's been told to you, you'll NEVER have the answer until YOU ask the question.

Once this conversation occurs (self-initiated by the individual or the team) THAT is where true learning can occur. The trick is to foster an environment that will stimulate these types of questions. If you can show them that they want an answer to the problem that interfaces solves, well, then THEY will ask the question themselves.

One good example demonstrating the usefulness of interfaces follows:

You've been assigned to be a bouncer at an international math convention. You've been told only to let people in that can supply a correct answer to the question "What's two plus two". Since this is an international event there are naturally many people attempting to enter that speak many disparate languages. At first your tactic is to figure out (or guess) what language a person requesting entrance speaks, then finding an interpreter that speaks the same and ask the question through him. It turns out that this works, and soon you learn to recognize some of the languages quickly and now know which interpreters speak this language, BUT it sure is a pain when someone that speaks a language that you can't identify outright shows up and you have to spend all that time to figure out which it is and then find an appropriate interpreter. So, knowing that there has to be a better way, you try to noodle out an improved method to do your job, and that is when it comes to you. You get a ream of paper and some marking pens and each time someone comes up to get into the convention, you write the following on a sheet of paper:

2 + 2 =

Lo and behold, it works! Each person quickly provides the answer. You don't have to figure out what language the person speaks or find an interpreter. Heck, you don't even care what language they speak, they just answer the question because they all know math! Instead of figuring out each case individually you've used the "IKnowMath" interface that each person attending the math convention understands.

Answer 3

An Interface is a Contract. It just specifies what a particular category (hard to get around the word class here) of Class is supposed to offer as a public API.