Is Microsoft Against Oo
Is Microsoft Against OoIt has been suggested by some and my own observations that Microsoft's philosophy tends to shun ObjectOrientation and ObjectOrientedProgramming. They add it in eventually to seemly try to get bullet-points in brochures, but it does seem that Microsoft never was very enthusiastic about much of OO, especially inheritance.
(Whether this is a good or bad thing probably depends on whether you like OO or not.)
Coming from the Microsoft world let me say the answer is a resounding hell yes they are against it. They actively teach against it in all their tutorials, I was a programmer for 3 years in a Microsoft only shop before I even heard OO, and most of my colleagues would agree. Now a happy OO programmer having recently removed the Microsoft blinders.
Any speculation on what drives them away from it?
Honestly... I think it's because they're tool vendors... they want developers as customers, not competition. It's in their best interest to keep their herd dumb. Were they to promote good techniques they might find their market drying up. There are far more programmers just barely capable of VB than of those that would understand the good techniques, I'd say they know their market quite well.
{But wouldn't such pressure also apply to Sun, Borland, etc?}
MicrosoftCorporationBad?, OpenSourceGood?? Hmmmmm. I use MicrosoftCorporation tools for OO development. They seem to work just fine. I know plenty of other people doing the same. I can't help but feel that the above is wide of the mark in several respects:
Don't get me wrong, I didn't say you can't do OO with their tools. I'm saying they don't promote OO as their strategy. If you were to sample MSDN, I'd imagine you'd find about 90% of the content is pushing the procedural recordset based paradigm. Microsoft doesn't consider OO good practice, many of their articles say so by saying OO doesn't scale well. None of sample applications use a decent OO model, even their recent rewrite of the .NET Petshop was very poorly written with most of the effort going into speed over maintainability. .Net is great for doing OO, they just don't really promote that strategy.
Microsoft has chosen the right strategy, OO or not OO. That is: fewer lines of code, more wizards, more component oriented, put the damn data on the damn screen. As a matter of fact, the degree of OO-ness in any serious software engineering effort should be at best a secondary factor. --CostinCozianu
Put the damn data on the damn screen works great when software is simple, OO helps when stuff starts getting complex. There's room for more than one way.
OO helps when stuff getting complex and some OO is helping stuff getting more complex. See PetStore, or ThePetstoreFiasco or EjbFlaws. We should be in the business of pursuing simplicity and elegance as per EwDijkstra. When OO is simple and elegant, OO is the way and Microsoft really doesn't stand in your way of pursuing OO. But it's not our business to pursue OO for OO's sake.
{Example of OO "fixing" complexity?}
Agreed, simplicity is king, and the OO approach is often the simplest, but not always. However, PetStore was meant as a design pattern sample. It squeezed everything in so you'd have a reference app. No real app would use every single J2EE pattern. Bloated code can be written in any paradigm too, it doesn't mean all OO looks like that. If an algorithm is sufficient to solve the problem, then a function or procedure is sufficient, no object necessary, you should be prepared to work at any necessary level of abstraction.
Microsoft have pushed COM for years, so they are obviously not against OO per se. However, their tools (I'm thinking particularly of MSVC++) have concentrated on making it easy to make COM objects rather than doing OO in the native style of the development language itself. I can see the business sense in this: by encouraging developers to use COM and discouraging them from using standard language features they tie their users into MS tools and MS operating systems and foster the development of objects that can be easily be used from VB and therefore encourage the use of VB, so tying more users into MS tools and operating systems and fostering a requirement for more COM objects, which requires more developers to buy their C++ tools... It's a vicious/virtuous circle, depending on your viewpoint.
I think that they just came to the same conclusion that I have more or less: Oo is less useful for "business modeling" than for networking and communications utilities. Thus, COM targets the C++ love-to-play-close-to-hardware crowd.
Also, "doing OO in the native style of the development language itself" means doing it over and over in the native style to get the functionality you need available to all languages. Unless you do something like the .Net CLR. Hang on a minute, they did!
I think .Net answers the question the page poses. They're not against it.
Ambivalent?
{My take on Microsoft and their examples and suggested practices is that it is written for 3 reasons: 1) it is easy for inexperienced programmers to understand; 2) the examples are often simple as they want to present a solution in limited space; 3) they want to make Microsoft tools look easy to use for entry level programmers and PHB's "see how easy it is to write a web app? Don't bother with that [Open Source|Oracle|IBM|Borland] junk, our stuff is *easy*." I do feel this creates poor programming proctices and over reliance on tools.}
I don't like a lot of things that MS does, however, I have to side with them on OOP. OOP has proven a general failure for business applications and business modeling. OOP makes a lot of assumptions about stability of interfaces, but business interfaces are not stable the way they tend to be in systems software. Thus, either you build a lot of meta-infrastructure to handle the changes semi-automatically, or you don't marry your code to heavy, static, hierarchical interfaces the way that OO code tends to. Microsoft does not tend to encourage meta techniques, so they lean toward simplicity to simplify code change instead. I would fault them for their anti-meta stance, but OO is not a fix either. --top
<edited rant into civil approximation; wordings are not those of the original authors:>
Top, the problem is that you don't know OOP.
No, the problem is that you can't prove any benefits of OOP via something based on the scientific process. You only use anecdotes, not true evidence. Can you point to evidence you feel is good, public evidence, but to only those who understand it?
</end edited rant>
As rant editor, could you explain to me what you mean by "but to only those who understand it?" ...I don't understand your phrase. -- Doug
I don't either. It was claimed that I don't like OO because I allegedly don't understand it (IfYouDontLikeItYouDontUnderstandIt). Thus, I was just mirroring the claim and asking for examples containing such claimed property. --top
EditText of this page
(last edited January 21, 2007)
or FindPage with title or text search