Return to Answer

Every class has an interface :

• Interfaces may be explicit, like when classes implement some interface or conforms to some protocol;
• Interfaces may be implicit: it's what a class defines top be visible from the outside and to be used by other class, hiding the internals.

You might for example read a lot of advices about the use of interfaces in patterns in the GoF, but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, just referring to an implicit class.

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. At least their implicit interface. The key is to see it as a black-box, i.e. think of it as if someone else could rewrite it and you wouldn't know its internals. This is not overenginering. It's just OOP.

You would go for explicit interfaces in the following situations:

• You find out that a class in your design should be replaceable with equivalent classes.
• You want to reuse implicit interfaces, or part of them, potentially with a family of potentially unrelated classes.
• You want to force yourself to think in terms of abstraction, and use language support for this purpose.

If you start to get stuck about the granularity of such an explicit interface, wondering if and how and why you might need to segregate it further, then you should take a deep breath, and just go on with a first version of your new interface, and if needed refactor later.

Every class has interfaces either explicit (implement some interface or conforms to some protocol) or implicit (features usable from the outside, hiding the internals).

You might read a lot of advices about using interfaces or programming to interfaces which refer to implicit interfaces. One example is GoF: most of the examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, just referring to an implicit class.

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. This is not overenginering. It's just OOP. You would go for the extra effort of explicit interfaces in the following situations:

• a class in your design should be replaceable with equivalent classes;
• implicit interfaces or part of them, are to be reused, on objects of a broad family of potentially unrelated classes;
• deliberate use of language support to force you think in terms of abstraction.

If you get nervous or stuck regarding the granularity of explicit interfaces and if further segregation is needed, then take a deep breath and just go on with a first version of your new interface. If you find out later that the interface should be split, you can always refactor.

Every class has an interface :

• Interfaces may be explicit, like when classes implement some interface or conforms to some protocol;
• Interfaces may be implicit: it's what a class defines top be visible from the outside and to be used by other class, hiding the internals.

You might for example read a lot of advices about the use of interfaces in patterns in the GoF, but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, just referring to an implicit class.

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. At least their implicit interface. The key is to see it as a black-box, i.e. think of it as if someone else could rewrite it and you wouldn't know its internals. This is not overenginering. It's just OOP.

Some of these implicit interfaces may need to be reused for different classes either in full or in part. Sometimes unrelated. This is the moment when you go one step further and create an explicit separate interface.

Every class has an interface :

• Interfaces may be explicit, like when classes implement some interface or conforms to some protocol;
• Interfaces may be implicit: it's what a class defines top be visible from the outside and to be used by other class, hiding the internals.

You might for example read a lot of advices about the use of interfaces in patterns in the GoF, but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, just referring to an implicit class.

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. At least their implicit interface. The key is to see it as a black-box, i.e. think of it as if someone else could rewrite it and you wouldn't know its internals. This is not overenginering. It's just OOP.

You would go for explicit interfaces in the following situations:

• You find out that a class in your design should be replaceable with equivalent classes.
• You want to reuse implicit interfaces, or part of them, potentially with a family of potentially unrelated classes.
• You want to force yourself to think in terms of abstraction, and use language support for this purpose.

If you start to get stuck about the granularity of such an explicit interface, wondering if and how and why you might need to segregate it further, then you should take a deep breath, and just go on with a first version of your new interface, and if needed refactor later.

Every class has an interface :

• Interfaces may be explicit, like when classes implement some interface or conforms to some protocol;
• Interfaces may be implicit: it's what a class defines top be visible from the outside and can be used, hiding the internals.

You might for example read a lot of advices about the use of interfaces and how to use them in patters in the GoF, but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, referring to an implicit class.

So you always need to think about an interface when you develop. The key is to see it as a black-box and not to rely on the concrete implementation you're writing for it. This is not overenginering. It's just OOP.

Some of these implicit interfaces may need to be reused for different classes. Sometimes unrelated. This is the moment when you go one step further.

Every class has an interface :

• Interfaces may be explicit, like when classes implement some interface or conforms to some protocol;
• Interfaces may be implicit: it's what a class defines top be visible from the outside and to be used by other class, hiding the internals.

You might for example read a lot of advices about the use of interfaces in patterns in the GoF, but most of the code examples in that book are C++ code, sometimes with pure abstract classes (the C++ equivalent to interface), often, just referring to an implicit class.

So don't get mislead by ambiguity of words: you always need to think about interfaces when creating classes. At least their implicit interface. The key is to see it as a black-box, i.e. think of it as if someone else could rewrite it and you wouldn't know its internals. This is not overenginering. It's just OOP.

Some of these implicit interfaces may need to be reused for different classes either in full or in part. Sometimes unrelated. This is the moment when you go one step further and create an explicit separate interface.