Eric Newcomer wrote:
> One reason this topic comes up is that objects are not the best way to
> model the world in software. Services are better, and simpler. It is
> too difficult to try to think of all functions the world needs
> automating in terms of things with operations. GetCustomerInfo is a
> valid function but to implement it you shouldn't have to model a
> Customer object.
I think that there is hair splitting going on here. Objects come in many
different forms. The binding of data values to program storage creates
"objects". If you think that you need to strongly separate objects that have
code and objects that are only data, I think you are being short sighted.
The whole point of OO programing is to associate the types of "programatic"
actions that certain data uses, with the data. That doesn't limit what you can
do with the data, that only provides a convenience for programmers and system
review so that one doesn't have to search 100000000000 lines of code to find
which functions can be used on a particular type of data item.
Good OO design says that changes to an objects state happen closer to the
object
rather than at a distance. This concept is what often compels remote system
designers to make remote calls to objects without consideration of the latency
and frequency which when put together create overhead that can be unacceptable.
What one has to arrive at is the concept of batching, or grouping of operations
into a form that enhances the system. One might have 100 Orders, and need to
cancel them all. Rather than making 100 remote cancel() calls, you should
provide a service which can take a collection of orders and cancel them closer
to the objects where effeciency is possible, and even local transactional
behavior can be used which might be cheaper (just use the databases facilities)
in the long run.
Objects are not the impediment to good system design. Complex systems create
complex scenarios, and need simplifying technologies. Objects can simplify
your
system when used correctly and effectively.
The software industry is continuing to employ undereducated programmers as
system architects who are creating horrible systems that just do not perform.
It's possible to design bad systems using many types of technologies. It easy
to create coupling between objects and bad system designs with any programming
environment.
I'd like to hear more about specific systems and architectures which don't work
with objects. Your conviction has captured my couriosity.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> 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/
