Friday, February 27, 2009

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

4 comments:

Rick Strahl said...

Try and see how well subclassing in the class browser works in VFP with CODE classes.

And you use VCX classes? You should be stood against the wall and shot! Seriously!

At least the VS class designer can represent a full class hierarchy unlike the VFP class browser which at best shows one level with links to everything else.

There are shortcomings for just about everything and arguing the flaws of the VS class designer in comparison has got to be one of the most petty things every. The VFP class designer is a cruel joke inflicted on VFP developers years ago. So close yet oh so far on what a class browser is supposed to do.

FWIW, I've never used the class designer in VS for anything but viewing classes. I never used the VFP class designer either for anything but fixing a problem which incidentally was caused by VFP data file corruption - the number one reason to avoid VCXs like the plague. It's more of a pain in the ass than creating a class - yes even a VCX class.

So WTF? You don't like code - maybe you need a different job...

There are some good points to be made about shortcomings of visual control design in .NET (like lack of composition inheritance) but this is just a cheap shot and a bad one at that.

Mark Gordon said...

Rick,

I assume you are the same Rick Strahl from west wind which makes your comments really puzzling.

I am well aware of your work and your level of attention to, what some may consider, petty details. Are you saying we should expect less from the Visual Studio development tools and ignore petty details because the tool was developed by microsoft or should we just be cool and spin Visual Studio like good little cheerleaders?

So when you shoot me are you going to put Ken Levy on my right or left for developing the class browser and shoot him as well? The developer must be at least as incompentent as the end user. Forgive me for using a standard part of Visual FoxPro, how foolish to assume it actually could be used in a "productive" manner.

I believe the Stone Field data toolkit written by Doug Henning and many of the VFP frameworks (both native vfp and 3rd party) all rely very heavily on VCX files. More importantly, I have clients that use your tools, most of the classes are contained in VCX files but you said you never use the VFP class designer. Then you post on your website a blog entry about using the class browser with PRG'S.

Let me refresh your memory and quote part of your entry from your website:

Wednesday, January 03, 2007, 9:07:00 PM

"This isn’t exactly news, but in Visual FoxPro 9.0 - unlike in previous versions - the Class Browser works with PRG classes which is very nice if you have PRG files with complex classes or multiple classes. I’ve known this for some time, but the CB is not exactly obvious to work with and there’s always the document window right?"

So I'm confused ?

I have used VCX files in all my applications and my experience is data corruption occurs very rarely. When it does happen most of the time it is due to user error deleting a class at the wrong level or a lock up, to reiterate this is rare.

Moreover, the form and report designer along with many other areas of VFP store code and meta data in memo fields of dbf files like the VCX'S and I doubt there are developers that hesitate to use the form builder, for example, due to SCX data corruption concerns.

I don't mind coding, however I do have a serious problem writing code in Visual Studio that wasn't necessary, in what are considered, "legacy" technologies. I think there are better uses for my clients money then wasting it on improving my typing skills.

Is the the VFP class browser perfect of course not. But I do have a newly found appreciation for it after using one that is completely useless in Visual Studio!

Was my post a cheap shot, no I really don't think it was. Maybe I'm a demanding user of Visual Studio, but a new technology should at least be as good (ideally better) as the tool it is replacing in "every" aspect including the petty details such as the class browser.

At any rate...

I'm glad we at least agree, I assume, on your last point.

Mark

Anonymous said...

Great job on the Visual Studio vs Visual FoxPro posts! I followed your debate with Sam now Rick, I can't say you lack an opinion....Rick's comments trashing Visual FoxPro are disappointing. Rick is aware of FoxPro's benefits over Visual Studio, he's protecting his tool of choice....

bernardb said...

One of my major gripes with VS has always been that I cannot visually subclass anything. After all this product is called "Visual" studio, uses classes for absolutely everything but yet does not give me any tool to design these same classes visually. I have to type code? Please. I used to do that in Assembly language and that was streets faster.

Besides I ALWAYS use VCX classes (again I prefer the visual approach) and have had very little if no problem with data corruption using them. I also use SCX classes and absolutely refuse to use a form written in code. I design visually or not at all.

Finally someone else with guts to say what has to be said.

Good on you Mark. I enjoyed reading these posts.