A discussion with a friend who works mainly with Java has come to the old case of virtual-by-default vs. final-by-default.
When I come to declare a method, I can decide whether I want derived classes to be able to override it. Java does this by default, which kind of sucks because it opens up a way for people to override code you haven't intended on letting them override, just because you forgot to mark the method as final. C# makes all methods final by default, which kind of sucks, since you can forget to make a method virtual and thus limit the deriving class from doing things it could have done if you had marked the method as virtual.
So why not take a third road? Why not just be constantly explicit about what you want to do? I think all methods declared in C# should be required to have a 'sealed' or 'virtual' (or 'override') modifier on them. This way, you would never be able to get away with not making the decision whether derived classes can override a method or not.
But that's just a thought... :)
I apologize that it's been a while since I last wrote something here. The lack of content was due to the fact that I have been reassigned to a non .net project for the foreseeable future.
I do, however, want to share with you a school of thought I developed during my many months of creating infrastructure code and forming coding methodologies in my last project. Maybe someone has already thought of it before. If they have, let me know. :)
I like to call this school The Zero Trust Rule or Zero Trust for short .This would mean that while you enable a programmer to work over your program or code, you will do so under two guidelines:
- Never trust programmers to not make mistakes. About anything.
- Help programmers understand the err of their ways when they make their mistakes.
For an example of the first rule, let's take a simple scenario: MyClass exposes a property of type Object, but can only receive instances of type SomeClass. If the property receives a different type, it throws an exception.
This doesn't coincide with the first rule. The first rule clearly states that you should never trust any programmer (even yourself) to not make mistakes.
So we change the property to receive only objects of type SomeClass. This way, the programmer can not make a mistake of setting it to a different type.
A great example of the second rule would be the ObsoleteAttribute. In this case, when a programmer makes a mistake and uses an obsolete member, a compile-time warning is displayed and explains to the programmer what they had done wrong.
Visual Studio is another great example because it lets you know when you have a syntax error even before you compile, using red squiggly underlines.
This also applies to those of you who don't develop infrastructure code, because when your project enters the maintenance phase and if some one else was to maintain your code, they will make mistakes. Strongly type members. Use comments. Do not let them mistake.
The guidelines of Zero Trust have been with me all the way and helped me develop better software. I would recommend that you always have these two questions in the back of your mind:
- How can I force whoever uses this piece of code to make as few mistakes when using it as possible?
- How can cover the rest of the scenarios where I can't force the user to do the right thing?
Maybe someday everyone will think like this.
Do you follow this school of thought as well? I'd like to hear what you have to say.