c# - Interface / Abstract Class Coding Standard -

i spotted proposed c# coding-standard stated "try offer interface abstract classes". know rationale this?

the .net framework design guidelines have interesting things interfaces , abstract classes.

in particular, note interfaces have major drawback of being less flexible classes when comes evolution of api. once ship interface, members fixed forever, , additions break compatibility existing types implement interface. whereas, shipping class offers more flexibility. members can added @ time, after initial version has shipped, long not abstract. existing derived classes can continue work unchanged. system.io.stream abstract class provided in framework given example. shipped without support timing out pending i/o operations, version 2.0 able add members supported feature, existing subclasses.

thus, having corresponding interface each abstract base class provides few additional benefits. interface cannot publically exposed, or you're left @ square 1 in terms of versioning. , if expose abstract base class, there's little gained having interface in first place.

additionally, point made in favor of interfaces allow separating contract implementation. krzysztof cwalina argues claim specious: incorrectly assumes cannot separate contracts implementation using classes. writing abstract classes reside in separate assembly concrete implementations, it's easy achieve same virtues of separation. writes:

i hear people saying interfaces specify contracts. believe dangerous myth. interfaces, themselves, not specify beyond syntax required use object. interface-as-contract myth causes people wrong thing when trying separate contracts implementation, great engineering practice. interfaces separate syntax implementation, not useful, , myth provides false sense of doing right engineering. in reality, contract semantics, , these can nicely expressed implementation.

in general, guideline provided do favor defining classes on interfaces. again, krzysztof comments:

over course of 3 versions of .net framework, have talked guideline quite few developers on our team. many of them, including disagreed guideline, have said regret having shipped api interface. have not heard of 1 case in regretted shipped class.

a second guideline argues 1 do use abstract classes instead of interfaces decouple contract implementations. point here correctly-designed abstract classes still allow same degree of decoupling between contract , implementation interfaces. brian pepin's personal perspective thus:

one thing i've started doing bake contract abstract class possible. example, might want have 4 overloads method each overload offers increasingly complex set of parameters. best way provide nonvirtual implementation of these methods on abstract class, , have implementations route protected abstract method provides actual implementation. doing this, can write boring argument-checking logic once. developers want implement class thank you.

perhaps 1 best revisiting oft-touted "rule" derived class indicates is-a relationship base class, whereas class implementing interface has can-do relationship interface. make claim 1 should always code both interface , abstract base class, independent of specific reasons so, seems miss point.