Re: [service-orientated-architecture] Re: Keith on BPM, SOA, OO & Brown Paper

[William Henry]

Hi Gregg, You're right of course; there are several ways to do this. My point was not which sort of get Address() you would use. My point was bigger picture illustrated by this example. In the real world envelopes are not active at all. I don't ask an enveloped to give me an address. An envelope really doesn't have any "methods" or operations. It is inanimate. Keith was originally talking about modeling on "real life". But OO techniques don't always do this. A person reads the envelope (some machines do too). A person puts the address on an envelope (some machines do too). An envelope doesn't do this itself. Therefore an envelope would look more like a class with no methods (or a structure) and all the address information would be publicly accessible. A person or machine would be able to "get address" from an envelope. However most OO methodologies would put the method on the envelope because the person (or Customer object etc.) would get bloated if all the operations/methods for all inanimate objects in the system were put in the person object itself.  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".  But you are of course right. Once you cross the line, that it's okay to put these operations on inanimate objects, then there are different ways to do this - some more appropriate than others. Your example was good. I'm sure there are other examples where OO  techniques don't always model the real world.  Does this mean that OO is bad? Not at all. I love programming in OO. But does that mean it is suitable for all programming scenarios? Not necessarily. And consider this. Ask a business person what happens an purchase order. Sure they might very well describe objects involved in the process but they will describe a process or procedure that the order must got through in order for it to be fulfilled. And this process or procedure might merely mean that the order moves from department to department getting examined and augmented and having other pieces of information attached or generated as a result.  This might just as easily be modeled and developed in a procedural model. E.g. A form (or structure) moving from process to process etc.  Regards, William On Oct 8, 2006, at 7:12 AM, Gregg Wonderly wrote: William Henry wrote: > Also consider this: though there are several ways to model for example > an Envelope I bet you that most people would but a method on it called > getAddress() (and probably a writeAddress()), or some similar semantic. > Even though an Envelope is a very passive object. The idea that you > might put this method on a Person object and have the Address on an > Envelope as public might be more semantically correct in the real world > but I don't know many OO patterns that would bother to attempt it this > way. A Person object would just get way to bloated. We tend to put these > actions on the object (grammar) rather than the subject even when the > object is inanimate. So to assume that "OO" is somehow a perfect way to > model the world is not correct. What is at issue, is how these two objects interact. An envelope, when being used by a mail system needs to divulge and address. The question is whether a receipient or sender is set on the envelope, and the mail system asks for getReceipent().getAddress() and getSender().getAddress(), or what. In other systems, perhaps the envelope sender information is completely unnecessary to know, and so we might just have getAddress(), which delegates to getRecepient().getAddress(). In the end, you really do have to consider many different issues. And, practice makes (more) perfect in software design. This is why you really need to employ architects with domain experience that measures up to the complexity of the system. > Also there were a lot of OO people in the early days of OO that had > quite awful OO patterns. Many people latched on to these early patterns > and never forgot them. E.g. passing an object by value all over the > place - which people do all the time - ans some languages promote! In > the real world it's true that objects move around but people use > references all the time too. (This point does help your point about bad > programmers ;-) So perhaps the truth is closer to yours - but not all > those schooled in OO think it's harder to think this way. This is where we are at with WebServices. Objects are being passed by value everywhere. Gregg Wonderly __._,_.___ 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 __,_._,___