William Henry wrote:
> So my point was not about the various ways of doing getAddress() on an
> envelope but was on the fact that anything like it would be on an
> envelope in the first place if OO is truly modeling the real world. In
> OO we often don't model it exactly and actually encourage some practices
> that aren't "real world".
There are a couple of interesting points in all of this, from my perspective.
One, is the ability of developers to see that software layers can be
appropriately targeted with domain specific "methods" so that the software
implementation layer can be effectively developed and documented, and the
software business layer can be effectively understood and deployed. In this
case, the capabilities of the Person, and Envelope might not even be visible at
the business layer. Instead, there would be an object called MailHandler which
would take in Parcel, Postage, Sender and Recepient objecst and might create an
Envelope object to hold all of these things. Then, there is a domain specific
layer which speaks the language of the problem/solution and can be trivially
reused if Parcel, Postage, Sender and Recepient are all interface based designs
rather than implementation based designs. Then, you can make a Person be a
Sender or Recepient via a separate factory method on a MailSystem object such as
public class MailSystem {
public Sender asSender( Person p );
public Sender asSender( Business b );
}
In Java, we'd probably just create an anonymous Sender implementation, on the
spot as in
public Sender as Sender( final Person p ) {
return new Sender() {
public Address getAddress() {
return p.getAddress();
}
public String getName() {
return p.getName();
}
};
}
and not have to worry so much about extraneous classes. If that implementation
of Sender needed to be Serialized, you'd want to create a real class instead so
that the inner class dependency was not a problem (a Java detail).
These kinds of wrapper things using interfaces is what makes it possible to
trivially retarget concrete classes at new problems. The solution domain
language of the API is important for whatever problem domain is being targeted.
These extra interfaces and extra objects can become burdensome if you go hog
wild. But, separating implementation and responsibilities in this way is a
form
of decoupling which can empower you to make other changes more trivially than
you might imagine. In particular, with Java remoting via RMI/Jini, by having
some of these things decoupled from the objects themselves, you can send off
remote access to "parts" of the object without exposing/transporting the whole
object.
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/
