What does Microsoft have against OOA/D?

My guess is that it's because Object oriented development wasn't invented by Microsoft, but it sure seems that they have it out for OOA&D.

Of course, you can go back a few years and clearly see how they were dragged kicking and screaming into the OO world. Take VB4. I still have the box. It clearly says it's an "Object Oriented RAD" environment.

Forget for a minute that OO and RAD are two (nearly mutually exclusive) different things. RAD is designed to get stuff out the door quick. OO is designed to make what you build more supportable, even though it may take longer to build. But, let's ignore that.

VB4, for all it's "OO" claims was to objects as Donald Trump is to good hair. There was no inheritance, no data protection. About the only thing even vaguely OO was polymorphism but that was an accident due to the fact that VB supported late binding of variables.

Not a shock it was that MS' web platform (ASP) relied on VBScript and JScript. JScript was no more OO than VB. Well, to be fair, it had the keyword "object" but you couldn't inherit them or protect them. In fact, you could "superclass" them -- meaning you could actually change the API of the parent. They also were pretty loosely scoped and properties defined in one were visible in another without even a direct object reference.

But that's all in the past, right?

Well, MS is better. C# is OO, no doubt. But you can tell that the gurus there still don't believe in this whole object junk.

For example. take Windows Workflow Foundation. If you create a new flow, the tool auto-magically creates a code-behind "designer" class for you. You can do all kinds of cool things with this -- you can create input and output properties and nifty methods that actually can change how the flow works at runtime. But you can't inherit it. It's a partial class (*choke*). (I once told my dev team that I'd slap the first on of them to use a partial class, but that's another story. )

So... hypothetical situation. Let's say you want to do something crazy, like, oh, i dunno, standardize the input and output elements in your flows, so that you can write a nice clean "workflow consumer" class that your junior devs can just use without having to mess with the whole delegate and workflow runtime junk. So, you think "aha! C# is OO. So I'll create a parent class with the inputs and outputs and implement a standard that all workflows need to subclass from that."

Nope. Notta. Can't do it. That would mean you'd be using OO. Not allowed.

And don't even try to inherit ASPX pages. Cuz, you know.. you wouldn't want to do that, of course. Heaven forbid that you'd want to pull out some of the common functionality. You can't really even inherit the code behind, since it, too, is a partial class (*grumble*).

To this day, I'm still P.O.'ed at them for the "virtual" keyword. Why on earth, would you want to ever make a method that you *don't* want to inherit and potentially override? Ok, maybe I can see it in a few unusual cases. But as the default?

Seems to me, every OO developer has created a class for some project. Six months later, they needed to extend it. They dutifully subclass only to realize that they forgot to make the parent method virtual . Or they just didn't think of it. Now they have to open up the parent class and change it. Look , isn't that the whole *point* of using OO? So that you *don't* have to change the parent class?

For that matter.. why the heck can't you inherit variables from parent classes? what were they thinking when they disallowed this: protected virtual string _x = ""; ? Oh, ok, i get it, you can do it with a property, but.. wha? Why create a property for one stupid string, just so I can inherit it?

As a side note, the whole property thing confuses me. Ok, I mean I get it. Properties replace the getters and setters in Java and, frankly, they're cool. But I defy anyone to show me the value of

public virtual string X

{get { return _x;}

set {_x = value;}

}

But yet, this is the default. So basically you're saying you need 4 lines of code to update a variable? come on. And it doesn't even help maintenance really. I mean, it takes 3 seconds to add it later if I need it. It's an awesome idea, but they're killing us with it's implementation.

As an example, take a look a workflows again. All input and outputs need to be properties. So you potentially end up with 200 {get...set...} combination that... provide.. which value again?

I think this is true because the reflection objects like properties. It's like the MS developers had a new feature and they wanted to use it everywhere. But sheesh.

Unfortunately, I don't see it changing. MS is stepping away from improvements in the core language and moving to improvements in the tools. Unfortunately, the tools won't support OO either -- they're mostly RAD-based. WCF is cool, but try to inherit the WCF transaction sometime. And going forward, I'd expect more things like SSIS and SSRS, and less things like Spring.Net, which actually makes use of inheritance. I do think it's telling that Java developers came up with Spring, while Microsoft came up with F#.

I don't think Microsoft's developers lack any mental capacity. I think they're smart folks. But I just don't think they've had the occasion to use OO. I think that's why none of their tools really support activity diagrams and sequence diagrams very well. (Well, Visio lets you do a few things with them, but we all know it was an after thought, and not a very full functionality.)

On the other hand, Microsoft has been very kind in adding code snippets to Studio. After all, if you can't inherit, you're left with copy/paste, right?