Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist, Microsoft
Course Topics
Object Oriented Practices
01 | Encapsulation
05 | Generics
02 | Inheritance
06 | Delegates Events and Lambdas
03 | Interfaces
07 | Functional Programming
04 | Abstract Classes
08 | Review Exercises
Interfaces
Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist
Module Topics
Interfaces
01 | Interfaces Defined
02 | Guideline: Interfaces represent Contracts
03 | Interfaces Practices
04 | Interfaces Results and Risks
Defining Interfaces
Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist
Defining Interfaces
An Interface defines a contract that can be implemented by many
unrelated classes.
Advantages of Interfaces
• Contract Definition
• Polymorphism among unrelated types
• Treat unrelated types similarly
Language Support for Interfaces
• Interfaces may be public, or internal
• Interfaces may extend other interfaces
• Classes can implement multiple interfaces
– Must implement all members
– Or be abstract (more later)
• May implement interfaces implicitly or explicitly.
Liskov Substitutability Principle
Let Φ(x) be a property provable about objects x of type T. Then
Φ(y) should be true for objects y of type S where S is a subtype of
T.
This applies to interfaces as well
Guideline: Interfaces Represent Contracts
Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist
Keep Contracts Small
• SRP is critically important for interface definitions
– The smaller and more focused the better
• Each interface should represent a single “feature” or “task”
– When you have related interfaces, consider inheritance
– Carefully!
Avoid Marker Interfaces
• A Marker interface is an interface with no members.
• They can be used to ‘mark’ capabilities.
• Require Reflection to find instances
Interface Practices
Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist
Practice: Common Abstraction
• Interfaces provide contracts for functionality
• Can be implemented by completely unrelated types
– Example: Enumerating a sequence
– Container
– Characters in a String
– Lines in a file
Practice: Interfaces for Client code
• You can specify required contracts for contract code
– Create interfaces clients must implement
• Algorithms can be open for extension
Practice: Interfaces for Test Doubles
• Test Doubles (in static languages) must have a type
• That type must be a substitute for the production type
– That often implies an interface that can be mocked.
• Necessary, but often not part of the application design.
Interfaces Results and Risks
Bill Wagner | Software Consultant
James Sturtevant | Senior Technical Evangelist
Good Outcome: Natural Implementation
• Implementing an interface should be “natural”
• Implementing an interface should be “obvious”
• Corollary:
– Implementations for interfaces should be complete.
Good Outcome: Complete Implementation
• Interface Implementers can create Complete Implementations
• Never see NotImplementedException
Risk: Copied implementation
• This is often caused by:
– Contracts with too many requirements
– Convenience Methods in Interfaces
• “All in one” interface
©2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Office, Azure, System Center, Dynamics and other product names are or may be registered trademarks and/or trademarks in the
U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft
must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after
the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.