However,
the choice is not always so clear, so let??™s consider some relevant issues.
When you implement a contract with an interface, you??™re defining a versioned contract.
That means that the interface, once released, must never change, as if it were cast in stone.
Sure, you could change it later, but you would not be very popular when all of your clients??™
code fails to compile with the modified interface. Consider the following example:
Public Interface IMyOperations
Sub Operation1()
Sub Operation2()
End Interface
Public Class ClientClass
Implements IMyOperations
Public Sub Operation1() Implements IMyOperations.Operation1
'Do op 1
End Sub
Public Sub Operation2() Implements IMyOperations.Operation2
'Do op 2
End Sub
End Class
Now you??™ve released this wonderful IMyOperations interface to the world, and thousands
of clients have implemented it. Then, you start getting requests from your clients asking for
Operation3() support in your library. It seems like it would be easy enough to simply add an
Operation3 method to the IMyOperations interface, but that would be a mistake. If you add
another operation to IMyOperations, then all of a sudden your clients??™ code won??™t compile until
they implement the new operation. Also, code in another assembly that knows about the newer
IMyOperations could attempt to cast a ClientClass instance into an IMyOperations reference
and then call Operation3(), thus creating a runtime failure.
Pages:
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202