Protected vs Protected Virtual c# -- The answer's in the code

While the internets have failed me this time (even msdn doesn't mention protected virtual), writing a quick console application saved the day. Consider the following code:

using System;

namespace protected_virtual
{
    class Program
    {
        static void Main(string[] args)
        {
            A a = new A();
            a.Method3();
            a.Method4();

            B b = new B();
            b.B_Method1();
            b.Method3();
            b.Method4();

            Console.WriteLine();
            Console.WriteLine("Press any key to continue...");
            Console.ReadKey(true);
        }
    }

    class A
    {
        protected void Method1()
        {
            Console.WriteLine("A.Method1");
        }

        protected virtual void Method2()
        {
            Console.WriteLine("A.Method2");
        }

        public void Method3()
        {
            Console.WriteLine("A.Method3");
        }

        public virtual void Method4()
        {
            Console.WriteLine("A.Method4");
        }
    }

    class B : A
    {
        public void B_Method1()
        {
            base.Method1();
        }

        protected override void Method2()
        {
            Console.WriteLine("B.Method2");
        }

        public override void Method4()
        {
            Console.WriteLine("B.Method4");
        }
    }
}

 
The code produces the following output:

A.Method3
A.Method4
A.Method1
A.Method3
B.Method4

Press any key to continue...

While this may seem trivial if you analyze the code closer you will discover the answer. First of all you'll notice that in Main Method1 and Method2 cannot be accessed, this is because they are declared as protected. However, Class B can access them because it derives from A. Refer to B_Method1() which is public but accesses the base Method1() from A. Also note that it outputs A.Method1. So my conclusion is that you would use protected if you only want a subclass to access the method. You would use protected virtual if you only want a subclass to access the method but also provide the ability for the subclass to extend or override it. Finally you would use public virtual if you want anyone to access the method but also want to allow a subclass to extend or override it.

Protected vs Protected Virtual c#

In c# you have the ability to allow someone to override your methods by using the protected keyword, however, you can also use protected virtual. One would do this when building a framework where one knew the domain logic at the time of creation but wanted to anticipate future change and/or extensibility. So the big question is.....what's the difference? Hopefully I'll have the answer in a future post, a cursory search on the internets revealed nothing as of yet. Stay tuned.

Server Scaling

In order to provide the most robust enterprise solution one consideration is state management. Ideally you wouldn't maintain state at all, this can be achieved but in some cases state management is necessary. When building applications using WCF should one even consider managing state on one's own or should a product such as http://www.scaleoutsoftware.com/ be employed? Any thoughts?

Interfaces, TDD and Visual Studio

One of the problems that we were having in an agile programming environment is that while we want to incorporate TDD we are having a problem transitioning into it. We have flushed out our C# development standards and while doing so I realized that, noting that one of our standards is that classes derive from an interface which defines it, we could easily use VS interfaces and the class design wizard to force us into TDD panacea or at least some semblance thereof. The idea is to create a class development workflow following these steps. Keep in mind that this is still in the idea phase and we are going to start using it soon, once we do the steps could change or you could adapt the changes to meet your needs. This was done using Visual Studio 2008

1. Create a new class design diagram in your project.
2. Create a new interface in the class diagram; populate properties, methods, etc.
3. Create a new class in the class diagram and have it inherit from the interface.
4. Using VS features implement the interface on the class.
5. Add a unit test project to the solution.
6. Create tests for the methods you want to develop.
7. Test, code, fix.....test, code, fix until you are done.
8. Rinse and repeat

Happy coding!