Hi SO architects!
I am an architect of the physical spaces...( it's not enough to say i am an architect anymore)
my research is on the ways mobile technology in particular cellphones are changing how a user percieves the physical space. I have been reading the last 40 emails of this groupe trying to undrestand what you are all saying.. and I have learned very intersting things that i will try to explain to see if i am not too off base.
first of all i undrestand that you say there are two ways to design these virtual spaces. one is OO and the other one is Process oriented... you are also saying that the choice between the two referes to how designers see the users of their virtual space. 1-if you think the user sees the world on procidural bases... meaning each person is a set of processes that is continually starting and ending and connecting to other processes... when we get
older then we be a more complicated process than when we are younger...then the designer believes that the user undrestands the world as processes and so designs like that.
2-some say that no! we are not merely sum of processes but we are also an entity an object with its own agency that is performing these set of processes. or our being is not limited to a set of functions...
this is particularly of interest to me. i am trying to define the user when he is equiped with mobile technologies and saying that this person is different from the Vitruvius Man and therefor requires the architects of the physical world to get to know him and his abilities better..to see how the user undrestands the world... Mitchell says that we have broken the bounds of our skins and now we are reconfigurable extended cyborgs.
from your definitions of a user as a set of processes i see a whole new way
of undrestanding a society and how it is relating to its physical environment and also how today its environment is reacting to the society...
thanks for your time and greate discussions.
Sara
student of Master of advanced studies at UBC
Gregg Wonderly <[EMAIL PROTECTED]> wrote:
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
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. __._,_.___
SPONSORED LINKS
| Computer software program | Computer software spy | Computer job |
| Database software | Discount computer software |
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
