|
|
|
|
|
|
by michaelfeathers
4865 days ago
|
|
|
One of the threads I was following on twitter last week was an exchange between a Microsoft architect and a unit tester. The tester was complaining about the lack of interfaces around a lot of the .net classes, especially in new features. The Microsofty countered with the increased risk of people rolling their own implementation of critical functionality and the increased demand on support that would produce. It's a poor excuse, in my opinion. We have the choice to treat software the same way that people treat hardware products. Give notice that you will not be supported if you do things that are outside intended use. With appliances, this is called 'voiding the warranty.' The problem is that we have not developed a culture which accepts those sorts of agreements yet. The closest I've seen (and I've been tracking the testability issue for frameworks and libraries for years) is the Eclipse notion of soft-final. They used comments to indicate that you should not subclass particular classes. They could have marked them final but they chose not to in order to support their internal development. But, the message was clear: "if you subclass this, and a future version breaks you, it is your problem not ours." The fact of the matter is that language-based protection mechanisms are too coarse. They are an attempt to solve a social problem (what people are allowed to do) with technology and there's no way to get it right consistently. Better to leave it in the social sphere. |
|
|
Marking variables as private using naming conventions like foo._dont_mess_with_me is also often helpful. Tools like linters can warn you that you're doing the wrong thing (messing with object internals) but the language doesn't get in your way or force you to use things like reflection to do what you want.