Here’s the next round!
11. Property dialogs
In addition to designing objects for their actual visual interface, we design certain types of objects for how they will behave in the property dialog – whether visible and what editors they have available.
12. Designers (Workflow & UI)
In addition to designing objects for their actual runtime behavior, we design them for how they will behave at design time – visual designers, avoiding issues with instantiating base classes (WinForms disallowing abstract/MustInherit base classes), etc.
13. Design Patterns
Where possible, we design to patterns. Meaning that in addition to the details of our technology, we try to design to the lore of repeatable patterns.
14. Unit testing
In addition to designing for runtime behavior, we design to test. This is particularly evident with BDD/TDD’s use of MVC patterns because they test well. But it’s also true of other applications. If we are testing them well, we wrote them to allow good testing. Testing also raises scope issues.
The creation of our classes is dynamic in today’s world. The time of CRC cards when we actually thought we should get the properties close to correct first time out are gone. Renaming, switching parameter order, and more complex refactoring are common.
16. Interfaces (contracts)
This was actually in Booch’s book, and of all the things here perhaps doesn’t belong. However, in my world of the 1990’s we did not think in contracts. Interfaces are contracts in our world and they are arguably more important to get correct because of versioning issues than anything else about our objects.
17. Multiple assemblies
Assembly boundaries have become a critical point of visibility. Protected scope is more public than interna/Friend scope. Also, we do not have a protected and internal scope, only a protected or friend scope.
18. InternalsVisibleTo attribute
Assembly boundary scope visibility can be broken via the InternalsVisibleTo attribute. While not widely used today except in testing, this is an important break to scoping.
Overloads means the same method can have multiple parameters sets – meaning multiple signatures. This means it’s more difficult to define exactly what a specific method does. This is also an area where few programmers understand details of what happens, and generics alter the impact of the rules.
20.Perf and virtual table issues
We shouldn’t program for this because the impact is too small. Unfortunately, Microsoft did and we are faced with an inflexible List class and a System.Collections.ObjectModel.Collection with few features. The impact on our code is we have to determine future needs to select the correct class.