Is object-orientation dead in the presence of service-oriented architecture?
I just talked with a respected practitioner and author in our industry about future directions and advanced topics; he thinks that we as industry still need to understand objects in the first place.
I agree; the level of detail were objects have a significant impact usually is dismissed for practitioners, and for non-practitioners it falls out of their attention.
In the context of this post, a practitioner is someone directly responsible for the design decisions of a software system, from its inception to the deployment and further evolution.
Nevertheless, OO should be dead in the context of distributed objects, as stated in Martin Fowler's First Law of Distributed Object Design: don’t distribute your objects.
Errant Architectures
Software Development Magazine April 2003
http://www.sdmagazine.com/documents/s=7897/sdm0304a/sdm0304a.htm?temp=src8Ub4XpT
Object-oriented design delivers value at a particular granularity level which is different than .NET Remoting or Web Services across the wire. .NET Remoting is closer to that granularity level when used across AppDomains in the same machine.
Some observed properties of different design approaches for take in account at designing are:
Structured design
Object design
Component-based design
SOA
Granularity
Very fine:
Method level
Fine:
Abstract data type level
Medium:
Interface level
Coarse:
Application façade level
Coupling
Tight
Loose
Very loose
Communication scope
Intra-application
Inter-local application
Inter-remote application
Inter-enterprise
The June 10, 2003 Connecticut Object Oriented Users Group meeting about Service Oriented Architecture held a related discussion
http://www.cooug.org/Main/Newsletters/Jun03NL.HTM
In fact, service-orientation is an old object-oriented design concept, as stated by Timothy Budd since first edition of "An introduction to object-oriented programming", section 2.3.5: A service-centered view. This is one thing many people miss about object-orientation: Abstract data type design, where the behavioral interface is not just a mere set of function calls but a collaboration protocol based on 'sending messages' instead of just functions calls.
SOA is the same concept at another level of abstraction, an architecture style useful if and only if, we don't mix abstraction levels when designing services. Andy Hunt and Dave Thomas wrote about some signs of mixing abstraction levels in their IEEE Software May 2004 article: "OO in One Sentence: Keep It DRY, Shy, and Tell the Other Guy".
PingBack from http://softwareinformation.247blogging.info/marco-dorantes-weblog/