Reading over my last post on behavioral extensibility, I realized that there werea couple of points that I failed to make last time around.

I'm not saying that behavioral extensibility is necessarily bad -- just potentiallyexpensive. Leaving a virtual method unsealed is a great way to plan for the future, providedthat you have an inexpensive communication channel availalble via which you can talkto the people doing the extending.

If I extend a class that you've originally written to do different things, I needto communicate those semantic changes back to you if you are going to interact withthose extensions. This is not prohibitive when you and I are developers sitting nextto each other. However, if you and I are both large enterprises that are geographicallyseparate the time cost of communication between us is very large. Thus, we want tominimize the amount of out-of-band communication required to do business. One wayto accomplish this is by limiting was to transparently change the behavioral semanticsthat we both depend on.

The point is, the behavioral semantics of a service are an implicit part of the servicecontract between two participants -- and leaving yourself open to unbounded behavioralextensibility means that you might break that contract inadvertently in a way that'sreally hard for a compiler to detect.