Design of interface and components

A key advantage of component software development using multiple interfaces is that your components can evolve by implementing additional interfaces as the need for new functionality arises. For example: As the BankManager system evolves into, say, the BrokerageManagement system, components that provide savings and checking account objects can be replaced by components that provide MoneyMarketAccount and MultiUseAccount objects.

A legacy application compiled to use personal accounts may be still be able to function quite nicely using the new account classes, as long as it doesn't include code specific to personal accounts.

• The key points to remember when using multiple interfaces in this fashion are: After an interface is defined and in use, it must never change. For details about interface invariance, see  Interface Definition and Factoring Design Considerations.
• If an interface needs to be expanded, create a new interface. For details, see  Interface Definition and Factoring Design Considerations.
• If versioning is an anticipated issue, consider creating an abstract class. Abstract classes are classes that must be implemented and cannot be instantiated on their own. An abstract class can be versioned by adding additional methods, properties and events as the need arises. By making the required change to the base class, the inheriting classes can incorporate new functionality without the need for changing all of the references to that class, as you would have to do with an interface. For details, see  Recommendations for Abstract Classes vs. Interfaces.
• New versions of components can provide new features by implementing new and expanded interfaces.
• New versions of components can support legacy code by continuing to provide old interfaces.
• New versions of applications can take advantage of new features (that is, new and expanded interfaces), and if necessary can be written so as to degrade gracefully when only older interfaces are available.