Source Code Doesn't Lie #3 - The Visual Studio Class Browser

The heart of any object oriented application development should be the class browser. While there are numerous benefits to following object oriented design patterns, the two benefits I want to discuss are inheritance and programming code reuseability. Given there are few things in life that suck less then the Class Browser found in Visual Studio (well .BLOAT does come to mind to think of it), it defies logic why the Visual Studio Class Browser has not been corrected.

Before moving to looking at the class browser lets review a simple example of how inheritance works.

Lets say we have a base class called "vehicle", and this base class has certain functionality (methods) such as "Turn on Engine", "Turn Off Engine", "Make Vehicle Go", "Make Vehicle Stop", "Motor" along with some properties that tell us what is happening to the vehicle: "Are headlights On", "Is Motor Oil Full", "Are Seat Belts Fastened" etc....

Next we are going to build a benz and a septic tank truck (class). Instead of building these classes from scratch we can start with the vehicle class and subclass it. By doing so we gain access to all the functionality found in the original vehicle class and we simple build upon it.

By writing code in this manner we know the foundation is stable and tested i.e. the vehicle class. Besides that let's say we come up with a new property like "Is Transmission Fluid Low" instead of adding this to both the benz and septic tank truck we only need to write the code into the vehicle class because the benz and septic tank are inherited from the vehicle class, this new property is there and ready for us to use. Neither the benz or septic tank truck have to worry about everything going on behind the scenes to make "Is Transmission Fluid Low" work.

So it should be clear why this is a great programming model and a huge time saver.

The purpose of the class browser is to allow us to work with these classes in a "productive" manner. Now let's compare the legacy Foxpro's class browser to that of Microsoft newest technology advancement, Visual Studio's Class Browser, to see if perhaps we can Develop at Light Speed using Visual Studio and maybe Microsoft's slogan for Visual Studio is correct.

Below is the legacy FoxPro class browser. It is the standard explorer interface. For the purpose of this sample I added a UI control and subclassed it to prove it could be done and to point out this is something that CAN NOT be done in Microsoft newest tool Visual Studio, yes this is a WTF moment! The reasons why this is important is for developing a UI layer in N-TIER applications. The other thing that is noteworthy in FoxPro's class browser, class inheritance is performed in the class browser NOT in code like in the great Visual Studio 2008.
















Double clicking on a class allows you to drill into the class browser code environment where you can create proprieties, methods and add programming code. With the legacy Visual FoxPro Class Browser you have a "productive" environment to get your work done. You have a property sheet that displays all the proprieties, events and methods for the class. Double click on the method in the property sheet you want to work with and a code window opens that only displays code for that method furthermore there is a "view parent code" button that brings up a window that contains the code in the base class for that method. Of course you have the option to export the class from the class browser to a file and work with the code outside the legacy class browser .




















Now lets examine the Great Visual Studio's Class Browser. It looks flashier then the VFP class browser but that is where the benefit, if that even is one, ends. It is entirely symbolism over substance. More importantly there is not a way to subclass the .BLOAT UI controls using the class browser, remember this is something the legacy FoxPro Class Browser could do.























After the class diagram has been constructed you switch to, what I refer to as, Visual Studio's DOS MODE and you are basically digging through code to do everything that needs to be done with the classes. Unlike the legacy Visual FoxPro's class browser, Visual Studio doesn't provide you with a productive code environment instead we are given a text editor with intellisense to maintain the code.

Below is the code the simple vehicle class structure generated that we have to maintain using Visual Studio 2008 glorified text editor.

using System;
using System.Collections.Generic;
using System.Text;

namespace sample
{

class Vehicle
{

public int IsOilFull
{
get
{
throw new System.NotImplementedException();
}
set
{
}
}

public int AreHeadLightsOn
{
get
{
throw new System.NotImplementedException();
}
set
{
}
}

public int AreSeatBeltsFastened
{
get
{
throw new System.NotImplementedException();
}
set
{
}
}

public void Motor()
{
throw new System.NotImplementedException();
}

public void TurnEngineOn()
{
throw new System.NotImplementedException();
}

public void TurnEngineOff()
{
throw new System.NotImplementedException();
}
}

public class Benz : Vehicle
{
}

public class SepticTruck : Vehicle
{
}

It should be clear the Class Browser in Microsoft's Great Visual Studio 2008 is about as useful to developers as an Indian Saris is to Jenna Jameson.

Now you are thinking Mark that only is your opinion of the Visual Studio Class Browser. But oh not so Markus Egger MVP, VS cheerleader and editor of code magazine wrote the following in his blog.

..."The class browser was the VFP workhorse tool, true. Especially in the early days of .NET I have often wished I had it, especially since OO is and always has been so important to me. I even considered writing one"...

To add insult to injury, with WPF Microsoft is moving away from this productive object oriented subclass programming paradigm for UI controls to the miserable XAML composition implementation. In a future post, I will explain in great and gory detail why Microsoft's decision to implement the WPF/XAML paradigm is misguided and flawed at best. Their decision can only be compared to deciding to spend Christmas in Iraq! As hard as it is believe the WPF tools suck even worse then what we currently have available to us in Visual Studio, I really didn't even think that was possible, but yes friends it is true leave it Microsoft to develop the impossible. Unforunately for developers in this case it is not a good thing!

I'm still trying to find out what Microsoft meant by "Development at Light Speed" in the context of the Great Visual Studio perhaps they are comparing Visual Studio to assembler? Maybe we will have more luck with my next post trying to figure this out...

The score sheet thus far:

Sample Application: Legacy FoxPro beats Visual Studio 2008 and .NET
Class Browser: Legacy FoxPro beats Visual Studio 2008 and .NET

Legacy Visual FoxPro: 2 points
Visual Studio 2008 and .BLOAT: 0 points

Maybe I should have used DOS Foxbase to compare against Visual Studio 2008 to give Visual Studio a chance.

Until next time let's all "develop at bloat speed" with Visual Studio 2008 and the 70k+ classes of the .BLOAT API wrappers.

.Mark