On 3/1/06, RADEMAKERS Tanguy <[EMAIL PROTECTED]> wrote: > Firstly, as i understand it, cohesion is a measure of how well the > methods in an object stick together, how closely related they are to > what the object is and does - i don't understand how an object with > get/set methods is inherently "more cohesive" than an object without > such methods.
Actually cohesion is a measure of how singular in purpose an object is, which I suppose may be what you mean when you say "how well the methods in an object stick together." Getters and setters don't necessarily make an object more cohesive, but having methods in the object that are external to the core purpose of that object (which is where I am predicting I have a fundamental philosophical difference with what you're saying here) would make it less so. > Secondly, an object shouldn't have any idea about the outside world, True, but the corollary isn't necessarily true, meaning the outside world might need to know *something* about the object. At a minimum the outside world (meaning the system at large) needs to know the object exists and how to use it, otherwise the object is of extremely limited use to the system. > but an object _does_ care about how it is used: this is why objects have > both public and private methods, this is where the whole concept of an > object's interface comes from, this is one of the fundamental tenets of > object orientation: an object interface embodies a contract that says > "if you use me in these very specific ways (list of methods and > arguments) i will work for you." But isn't that precisely what getters and setters are? Providing a public interface to the object's data seems to me to be nothing more than a list of methods and related arguments that allow other objects in the system to use the object in question. > <tr> > <td>#Product.getName()#</td> > <td><cfif Product.isPromo()>Special! > </cfif>#Dollarformat(Product.getPrice())#</td> > </tr> > > i'm sorry, but that the exact same code you would have written with a > query - the fact that you sprinkle on a few parenthesis and use > sexyCamelCasing to name your "columns" doesn't magically make it OO. True in that case, but if this were a query you also have less functionality than if this is a bean with getters AND setters. The setters are what you're missing with a query object. For output of multiple records I still use query objects in most cases. When dealing with single records using a bean-like object is a very flexible and powerful way to go. > When you implement getters and setters for > your private instance fields, you are exposing the values stored in > these fields to use and manipulation OUTSIDE the objects in which they > live. But if the data is *only* private and no one can get to it, what use is it to the rest of the system? OO systems are all about building flexible objects that can communicate with one another through publicly exposed methods. The control of an object over its own data comes in the implementation of these publicly exposed methods, not through whether or not something outside the object itself can manipulate the data. If an outside process such as someone filling out a form can't manipulate the data inside an object, I'm not sure what the point of having the object is in the first place. > Imagine you have an address object made up of a number of fields - > street, state, country, etc. If you go down the getter/setter road, you > are basically inviting code outside your address object to know too much > about what constitutes an address - and this "expertise" constitutes > tight coupling. I completely disagree with the notion that other objects in the system having to "know" they have to call getStreet() to get the street address is tight coupling. getStreet() is nothing more than a public method that renders the object usable to the system at large. Without a public interface the objects are essentially useful only to themselves, which greatly reduces their power. > Whether there is a private string field called "street" > or whether the string return value of getStreet() is computed at runtime > is irrelevant - why do i need to know that an address is composed of a > street in the first place? Because something else in the system might need to pull the value of the street address from the object for some reason? It sounds like you're making the assumption that the only thing the object will ever need to do is display itself. How does the system actually *use* the object if the object doesn't allow the rest of the system to communicate with it? > I have no idea whatsoever how an internal > combustion engine works or what parts it is composed of: i just know > that you push _this_ pedal to make it go and _this_ pedal to make it > stop. I don't see a distinction between pushing the gas pedal in your car and calling getStreet() on an address object. You have to know where the pedal is and that you have to push it down to go somewhere. If you don't know that minimal information, it's not as if the car is going to drive itself. The gas pedal is the publicly exposed method for telling the car to go. Without that you aren't going to get very far, but you don't need to know a single thing about *how* the car implements the go() method to drive. > If you add a > field to address and wind up having to change the order display view, > that should set off some warning bells in your mind. What sets off warning bells in my mind is having an address object know how it's going to be displayed. Your domain model objects shouldn't know or care how they're going to be displayed. Matt -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
