[导入]IS OO Dead?

I have seen and heard a number of conversations recently asking if OO is dead. I find this very disturbing and I want to stamp this one out once and for all

To quote my blog on “Is Remoting Dead”:

“Is OO dead?”  -  No! Nope! Niet! Non! Negative! Nuh-huh! [shake head vigorously]!!!

OO is *absolutely* relevant, useful, valuable, important, vital and positively NOT deprecated and obsolete. I don’t know where this message came from, but it is NOT true. 

However, OO does have some problems

• It does not lend itself well to building decoupled, flexible, dynamically addressable, ubiquitous services required by tomorrow’s systems.
• OO has not succeeded in bridging heterogeneous environments - building a system from parts littered across CORBA, J2EE, COM+, MSMQ, MQ, and other infrastructures is unfeasible at worst and enormously complex, difficult and expensive at best.
• OO tends not to work well where connections between objects are unreliable and/or have limited bandwidth and high latency
• OO systems are not best suited to dynamically binding systems together based on policy expressed between caller and service – coupling tends to be hard and immutable
• OO systems tend not to handle interface or contract versioning very well. This is of crucial importance when it comes to building long-living systems to which callers beyond one’s control are connected.

Our industry is now at an inflexion point. We have a huge number of systems running on a number of platforms. These systems are enormously capable, but they tend not to talk to one another – integrating these systems is usually complex and costly. 

Can we continue with these types of problems? No!

This is why it is so crucially important to understand and adopt a Service Oriented (SO) mindset and approach (http://blogs.msdn.com/richturner666/archive/2004/03/02/83009.aspx) and why, in reality, Web Services are the most successful embodiment of SO. Does this mean that Web Services == SO? No. You can build Web Services that don’t follow SO principles and guidance, and you can build systems that DO follow good SO principles but aren’t widely accessible.  

I have seen a lot of angst and concern raised over our focus on SO and Web Services. This is understandable – if one listens to the FUD & misrepresentations on what Microsoft is or isn't doing with regards SO and our future Web Services Strategy, one could inaccurately assume that we’re abandoning what we’ve been doing for the last 15+ years in building OO technologies. BUT if one really takes the (small amount of) time and effort to think through what we ARE saying, then it all becomes a lot less scary.

SO and OO are complementary technologies:

• SO is how one thinks about building systems as a whole:
  • A System is a set of deployed services cooperating in a given task
    • Systems are built to change
    • Systems adapt to the introduction of new services after deployment.
  • A service is a program you interact with via message exchanges.
    • Services are built to last
    • Availability and stability are critical and the responsibility of the Service Owner.
    • Services are fractals – one service can contain other services, which can contain other services,  …
• OO is important WITHIN the service boundary
• OO technologies and approaches are used to build a service physically
• OO technologies store and retrieve data to/from internal data stores, perform calculations or business functionality, etc.
• This is “business as usual” for most developers  

Let me know if this isn’t clear or if the message just doesn’t come across here. We’re working on building content for you RIGHT NOW, so if this isn’t clear, I need your input.

文章来源:http://weblogs.asp.net/richturner666/archive/2004/06/08/151066.aspx