----- Original Message ---- > From: Sean Landis <[EMAIL PROTECTED]> > To: [email protected] > Sent: Sunday, August 31, 2008 12:10:26 PM > Subject: Re: Jini, JavaSpaces, JEE, some questions, and some other > development issues and ideas. > > I just had one thing to add and so I've deleted the rest. I agree with > all of Gregg's comments...as usual :-). > > ...deleted... > > >> Something bothering me about JavaSpaces entries is they force public > >> fields/variables. To me they should operate off the same assumptions > >> JavaBeans and serialization operate. EJBs work this way as well. Truly > >> those things should be compatible thus true encapsulation can > >> take place. I haven't figured out why entries differ from the other > >> specifications. > > Gregg gave a fine explanation of why this is so. I would turn that > around and ask, "Why do you care if a transfer object is transparent?" > > At first blush, it might seem like a nice idea to use business objects > as entries in a JavaSpace but I would argue that is a bad idea. Just > as it is a bad idea to pass BOs across web service boundaries, or > other distribution technology boundaries. > > If you do so, you quickly increase fragility in the system because > end-points must agree on the model and this is burdensome from many > perspectives. I'll give one example but there are many others. Our > Product Object, in it's complete form (from a DB field perspective) > has over 150 fields. This is too big to pass across the wire. > Furthermore, most uses of this object only care about a small subset > of this object. Further furthermore, we don't want certain of that > information to leak out to clients. > > We use transfer objects to resolve this problem. Transfer objects are > in the class of objects that exist merely for their state and contain > no interesting behavior. Here, encapsulation losses its value and > merely is unnecessary overhead. > > So I don't think the transparency of JavaSpace entries is a problem > from an OO design perspective. >
Yes, but this argument makes a lot of assumptions. Most importantly, it assumes that all objects belong to the client. In many circumstances domain specific objects need to perform checks on types of data, and be used in multiple situations yet remain solely in their domain; think back end processing systems and clustering. Method encapsulation only provides any real overhead in the sense of the static class loaded in a given JVM and thus influences that aspect of the application memory; fields and methods both influence class compatibility in the different locations JVMs. So, yes, forcing transfer objects to require public fields ensures those objects will only be used as purely transparent objects as they can introduce system instability if used in any other manner, and also can not be used to detemine how the values are set or if set consistently with state patterns of the object as encapsulation is not possible with required public fields, but to what specific end as there are many possible use cases. Along with the use of transfer data comes the burden of having code move the values into other objects for use in a particular domain: 1) Take domain object 2) Create transfer object 3) Move data from domain to transfer 4) Save transfer through steps which most probably require moving transfer again to domain and 1) Pull transfer object 2) Create domain object 3) Move data from transfer to domain 4) Use domain Where as were the specification to simply use the beans specification the domain object could be the transfer object in the cases it makes sense, and it could be used as needed versus being forced down a perceived path of best practice. I don't have your sources obviously, but probably you have domain objects mirroring many of the transfer objects as it would not make sense to have a full blown bean which can be used throughout your system yet its data not be stored and moved together. At some point you have to store and retrieve a product, and in different capacities at differing levels of complexity throughout the different domains of your application, so either you take multiple transfer objects to accomplish this goal, along with varying levels of encapsulation to represent this same data or in a single transfer object. Either way, at some point, you are most likely moving this data yet again into relatively simple domain objects for a given task, and not all of them requiring all those fields for the end result to be set. So, the need for developer choice and flexibility is still necessary from my perspective. In other words, it makes no sense to force a development model based on the notion of a better way of doing something when in many cases this wouldn't really be the best model. In many cases pure transfer objects are themselves forcing a lot of overhead from code complexity to extra classes and logic which must be executed when in reality they are not necessary until they are actually required. It is the same philosophy that logic doesn't need to be refactored or performance tuned to the Nth degree until it is necessary as attempting to do so before it is known to be necessary can introduce just as many issues as having done nothing at all. Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org
