Paul Hammant's Blog: .Net pitfalls
Being on a .Net project at a ThoughtWorks client site, and using Visual Studio 2003, it is apparent that code is not as refactorable as it would be for Java and IDEA/Eclipse. As such the cost of refactoring is higher. While this does not mean that we should do big-design up front instead of XP best practices, it does mean that we should try to avoid some pitfalls en-route to the perfect solution. The pitfalls as I see them are
- lack of Interface/Impl separation.
This should be used to facadify the internals of an application at pertinent boundaries. Despite the higher cost of i/i separation to maintain, it allows many very interesting possibilities. These include ease of mocking for the sake of unit-testing. Implementation hiding for the internals of an application (or layer represented by a facade). Without i/i separation we find that entanglement starts. Not a problem in an easily refactorable world, but a big one for where the IDE does not help refactoring. - PicoComponent principles
We should pass in comps via constructors and mark their member variables as readonly (blogged to death by me elsewhere on this site) - Allowing extendible classes and methods
That virtual/override business for methods. It is always best to allow override, but it is not so important for a codebase that is all yours (can be changed easily)