Maybe its old school but I always thought true object oriented design involved encapsulation of data AND behavior together whenever possible. The trick is to know how to model correctly it to maximize encapsulation.
One tries not to expose more than necessary. In order to expose as little as possible, generally the behavior usually has to live as close to the data as possible so the all the data doesn't have to be publicy exposed to implement a behavior. Behavior which acts across different object/class boundaries is more suceptable to breaking than behavior encapsulated in one object. Admittedly, there is no way to avoid behavior that acts across object/class boundaries but whenever it is possible, I would do it hands down. -----Original Message----- From: Brian Lee [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 4:54 PM To: [EMAIL PROTECTED] Subject: RE: Theoretical debate I think struts' concept of separating your actions from your data is admirable and should be followed. The concept of your value/transfer objects (basically the form) also having business logic sounds acceptable at first but rapidly becomes a nightmare when you try to use the same value/transfer objects in multiple processes. I think it's a generally accepted practice that separating data from logic is a "Good Thing"(tm). BAL >From: "Hookom, Jacob" <[EMAIL PROTECTED]> >To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> >Subject: RE: Theoretical debate >Date: Thu, 17 Jun 2004 14:57:31 -0500 > >I completely agree with what Crysalis is trying to push, also a >framework called VRaptor (vraptor.org) also pushes the same idea of >moving away from the procedural weight that Struts promotes. > >Look at JSF, do you have actions? No, JSF just updates your POJO beans >and calls methods on them. Why have an ActionForm or have to create >all of these Actions that are simply getter/setter adapters? Please >don't be too quick to retort to my supposed anti-struts mindset, but >there are other frameworks out there that allow direct interaction with >my business objects and don't require a heck of a lot of framework specific coding. > >--- > >Example: >To have a multi-page form with JSF, I just create a bean that sits in >Session scope that has a series of getters and setters. JSF will also >allow me to pre-set relationships to other objects at creation time. >Then, when I'm ready to submit the multi-page form, I just put in the >jsp #{myFormBean.submit}. No action mappings, only a managed bean >entry. > >With Struts, I have to create an ActionForm objects (can't just use a >business object I already have), and then create separate Action >objects to manipulate that ActionForm. > >--- > >-Jacob Hookom > >-----Original Message----- >From: Frank Zammetti [mailto:[EMAIL PROTECTED] >Sent: Thursday, June 17, 2004 2:29 PM >To: [EMAIL PROTECTED] >Subject: Theoretical debate > >Last night I was Googling for something and I stumbled across the >Crysalis framework. I was actualyl intrigued by the underlying premise >of it and I wanted to see what others thought about it. > >In a nutshell and in my own words, Crysalis >(http://chrysalis.sourceforge.net/) has the underlying idea that when >you develop in most MVC frameworks, Struts chief among them, you are >actually doing something unnatural and in a way at odds with basic OOP design. > >Think about a shopping cart example... If you were going to write that >in straight Java, not for the web or anything, how would you model it? >Most likely you would have a ShoppingCart class with a number of >methods in it, things like addItem(), removeItem(), totalPrice(), etc. > >In Struts, although you aren't FORCED to, what you GENERALLY do is >create three different Action classes like addItemAction, >removeItemAction and totalPriceAction, and each is called in response to a form submission. > >But isn't it kind of odd that your object model isn't following what >you probably think in your head is the right way, i.e., one class with >multiple related methods? Proper encapsulation and all that jazz, right? > >Well, Crysalis does just that. It's controller elements are regular >Java classes with multiple methods. What you wind up with is something >that resembles Remote Procedure Calls instead of numerous servlets as >controllers. > >In other words, you would create the ShoppingCart object just as I >described > >above, with all three methods. Then, when you submit a form, the >action is something along the lines of "ShoppingCart.addItem.cmd". >ShoppingCart is the class to execute, addItem the method and cmd is a >suffix to direct the request, just like extensions in your Struts apps >map requests to ActionServlet. > >The elements of the submitted form are treated as the parameters of the >method being called, making it rather elegant. > >I haven't gotten into any real detail on Crysalis, but I was interested >in getting other peoples' thoughts on the underlying principal (which I >*THINK* > >I've stated properly!). It was rather interesting to me because I'd >never reall considered looking at it that way, and certainly it's not >the way you typically approach a Struts-based application. It was also >interesting to me because I've for about four years now been preaching >here at work that we > >should write our applications as a collection of services that are >executed to form a coherent larger application, which is very much >along the lines of > >this (so I guess I actually HAVE looked at it this way in a sense, but >not exactly). > >Any thoughts? > >Frank > >_________________________________________________________________ >Watch the online reality show Mixed Messages with a friend and enter to >win a trip to NY >http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct >/01/ > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
