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

A copy of Head First design patterns or atleast the code examples from Head first Design patterns

Story telling like the way its done in Head First Design Patterns actually works great many time with skeptics

regards Edwards

Answer 2

I like the analogy of Legos, which are the classes and instances, and the pegs/holes on the top/bottom respectively as well as the sizes and shapes, which are the interfaces. For example, I may have a need for for a rectangular block with pegs in a grid of 2x4. These are the interfaces i'd be interested in - the pegged male/female inteface, as well as the rectangle interface. These can be satisfied by either an instance of the Rectangular Block Lego, or another instance of something "composed" of two half-sized Legos, of 2x2 pegs each, thereby still adhering to said interface. Because all the Legos have a common interface (male and female pegs) we can mix and combine however necessary, whether the piece comes from one of those new sets where I can build a giant robot ant, or is just a plain old square or rect. lego that comes in the giant vat you used to get back in the day. Hell, I can even mix official Legos with brand X legos, because the "male/female pegged interface" is so well understood.

Programming to interfaces allows us to mix and match reusable code components like we do Legos.

Answer 3

An interface is like a class's dress code. If a class implements an interface, its public members (its appearance to other classes, if you will) will include what the interface declares at minimum.

Answer 4

I would suggest you show them the benefits that can come from it. Imagine this C# scenario:

class User
{
    public String GetFirstName() { return "foo"; }
}

class App
{
    void Run()
    {
        User user = new User();
        String firstName = user.GetFirstName();
    }
}

Here we have a User class that will go and get a first name from somewhere and return it. Now your app is coupled to this class and it will be difficult to later change where you get first name from because you have used the User class everywhere. What would happen if you implemented a service and wanted to begin calling that service for the FirstName value? You would have a bit of refactoring to do.

Consider this approach:

interface IUser
{
    String GetFirstName();
}

class User : IUser
{
    public String GetFirstName() { return "foo"; }
}

static class UserFactory
{
    public static IUser GetUser() { return new User(); }
}

class App
{
    void Run()
    {
        IUser user = UserFactory.GetUser();
        String firstName = user.GetFirstName();
    }
}

Now you can implement the interface in any class you want like:

class UserService : IUser
{
    public String GetFirstName() { return "bar"; }
}

and just change the factory method like:

static class UserFactory
{
    public static IUser GetUser() { return new UserService(); }
}

and your app code will be none the wiser.

Answer 5

Tell them that interfaces are a trick word. Because the meaning is hidden right out in the open :P

Interfaces describe... an INTERFACE. They tell how you can interface with a class that implements it.

Answer 6

What are they familiar with?

When I learned C++, the teacher built on my existing knowledge of C, for example:

• Take the C library routines for file I/O: open, read, and close using a file handle
• Show how these can be rewritten as methods of a File class: create, invoke the read method, invoke the destructor of a File instance

Building on top of that, I might compare an IFile interface to a File class by saying that IFile exposes no implementation details at all: if the application uses IFile instead of File, then you can change the underlying file system / implementation details).