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
- 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
- Implementation of the interface must not crack the application (usually through interaction with other modules/application/tools)
- 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
- Code contracts can be enforced to specify pre- (post-) condition and invariants while implementing the interface.
- A set of cohesive responsibilities shall be represented by an interface. Responsibilities shall easily go together (Single Responsibility Principle)
- Interface must be simple, complex interface are usually broken into few simpler ones (Interface Segregation Principle)
- 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
- Factory/Abstract factory
If you enjoyed this post, make sure you subscribe to my RSS feed!