Recently I've been reading a book by Ken Pugh "Interface Oriented Design". It was quite a nice summary of what I had already been applying. Here is a short list of extracted spoken/unspoken rules a developer shall follow whilst using interfaces

1. Naming of interfaces and members shall be easily understood and meaningful. Name of the interface shall start with "I", indicating this is an interface and follow CamelCase notation. E.g.: IDisposable, IEnumerable etc.
   This rule has a connection to Barbara Liskov Substitution Principle (LSP). A subtype can be easily substituted with a parent type with application continuing working without errors
2. Implementation of the interface must not crack the application (usually through interaction with other modules/application/tools)
3. In case of a failure, application shall be notified. This is typically performed by throwing an exception. A bad idea would be to force a method to return an error code (in .NET or Java). Error codes are hard to debug and are often meaningless for production logging
4. Code contracts can be enforced to specify pre- (post-) condition and invariants while implementing the interface.
5. A set of cohesive responsibilities shall be represented by an interface. Responsibilities shall  easily go together (Single Responsibility Principle)
6. Interface must be simple, complex interface are usually broken into few simpler ones (Interface Segregation Principle)
7. Interface stretches through several types hierarchies. Interface reference shall be used where possible instead of a type reference (Dependency Injection Principle)

As it can be seen SOLID principles are widely applied within Interface Oriented Design. Additionally, I would also like to mention the design patterns that go nicely with IOD

• Adapter
• Composite
• Decorator
• Facade
• Factory/Abstract factory
• Proxy

If you enjoyed this post, make sure you subscribe to my RSS feed!