Another issue that can't be addressed by tools:

When building service-oriented systems, you don't want to make everything a service. Only those bits that are reusable should be exposed as services. Unfortunately, most of the current tooling out there tends to simply convert object interfaces into service interfaces.

Anne

On 8/28/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:

Hitoshi Ozawa wrote:
> What I'm trying to say is the OO is becoming embedded into other
> technologies
> such that not all people need to know it, just like not all web page
> designers now
> need to know HTML to design a web page. Knowing HTML and related
> technologies
> does help to create a better web page, but I think it's much better to
> hire graphics
> designers over people who just know HTML - more designers and few technology
> people.
>
The difference here is that OO is not a technology; it's a design
methodology, and I don't know of any way that that can be embedded into
tools. There are a few aspects of OO that could be measured by automated
tools (such as the degree of information hiding - OO suggests that most
of the properties of an object should not be exposed directly by the API
for that object), but most of the fundamental principles (such as
cohesiveness) are not of this type.

It's true that many developers don't really understand OO even though
they're working in languages such as Java or C# which are OO-friendly.
But what this means is that your projects lose most of the benefits
provided by OO. I'd say the same applies to developers working in a SOA
environment, BTW - if the developers working on service implementations
don't understand the principles of SOA, you're likely to end up with
something like a bunch of Web services glued together with an ESB.

- Dennis


__._,_.___


SPONSORED LINKS
Computer software program Computer software spy Computer job
Database software Discount computer software


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to