Dennis,
It's on selecting the right tools AND developing guidelines on using
these tools that's important. As you've stated, giving developers just a
tool wouldn't improve the situation.
Instead of giving developers just Java to work with, give them also
a set of patterns and a guideline on creating classes using these patterns.
Make sure they are using the patterns and following the guideline.
H.Ozawa
Dennis Sosnoski wrote:
> >
> 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
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
