Comments on: The getter, the setter, the thinking and the box http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/ nutrun Thu, 20 Nov 2008 12:35:28 +0000 http://wordpress.org/?v=2.6.3 By: keith ray http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-117 keith ray Fri, 14 Jul 2006 14:09:04 +0000 http://new-site.nutrun.com/?p=30#comment-117 http://c2.com/cgi/wiki?TellDontAsk Tell, don't ask. Single-responsibility methods do things, and maybe take parameters to help them do them. (Don't combine setters and doers, though.) http://c2.com/cgi/wiki?TellDontAsk

Tell, don’t ask. Single-responsibility methods do things, and maybe take parameters to help them do them. (Don’t combine setters and doers, though.)

]]> By: Reedo http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-116 Reedo Fri, 30 Jun 2006 17:48:50 +0000 http://new-site.nutrun.com/?p=30#comment-116 It isn't wrong to use more complex logic in getters and setters, because the very purpose of using a getter or setter rather than a public property is encapsulation: to allow the object implementation with its private data to change without breaking code that relies on it! Even if a getter or setter starts out as braindead, in the future the object can put any code there that should be executed when the property value changes or gets accessed. If it was just a public property and not a getter/setter pair, that code would have to be duplicated everywhere that the object's property is manipulated--outside the object--and that would be awful to maintain. It isn’t wrong to use more complex logic in getters and setters, because the very purpose of using a getter or setter rather than a public property is encapsulation: to allow the object implementation with its private data to change without breaking code that relies on it! Even if a getter or setter starts out as braindead, in the future the object can put any code there that should be executed when the property value changes or gets accessed. If it was just a public property and not a getter/setter pair, that code would have to be duplicated everywhere that the object’s property is manipulated–outside the object–and that would be awful to maintain.

]]> By: Paul Ingles http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-115 Paul Ingles Fri, 30 Jun 2006 17:22:46 +0000 http://new-site.nutrun.com/?p=30#comment-115 Eddy, Possibly, and as my Economics master used to suggest I answer every question with: It depends. In this instance, all we're talking about is the loading of data. There's no funky monkey-business with "if this child object doesn't exist yet, create it, and then return it". It's a slightly different use of the Lazy Initialisation pattern - where we're not really attempting to delay database access, rather instead to improve our test code. The benefit was a JUnit TestCase that we didn't need to edit every other testXxxx every time we changed our action. However, I have seen strange behaviour through too much logic in getters (primarily from my years of .NET work). In this instance though, I don't think it's doing too much more than what a standard getter would be doing. Eddy,

Possibly, and as my Economics master used to suggest I answer every question with: It depends.

In this instance, all we’re talking about is the loading of data. There’s no funky monkey-business with “if this child object doesn’t exist yet, create it, and then return it”.

It’s a slightly different use of the Lazy Initialisation pattern - where we’re not really attempting to delay database access, rather instead to improve our test code. The benefit was a JUnit TestCase that we didn’t need to edit every other testXxxx every time we changed our action.

However, I have seen strange behaviour through too much logic in getters (primarily from my years of .NET work). In this instance though, I don’t think it’s doing too much more than what a standard getter would be doing.

]]> By: Jaka Jaksic http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-114 Jaka Jaksic Fri, 30 Jun 2006 14:12:05 +0000 http://new-site.nutrun.com/?p=30#comment-114 It is not "wrong", but it may have unexpected side-effects if you use such classes with tools, such as Hibernate, which expect getters and setters (and constructors) to be plain and simple. I often put some extra code in those methods, because I find it convenient, but quite often funny stuff started happening afterwards, e.g. wrong values being read/saved to the database or getters/setters being executed at inappropriate times, like before the aplication was fully initialized. If you only use those classes yourself, in a controled way, then it's ok to have more complex getters/setters/constructors. If they are used by 3rd party bean handling tools, then you can still make them complex, but you have to be careful with what you do. You have to be aware that those tools expect these methods to be simple and that they can call them anyhow, at any time. It is not “wrong”, but it may have unexpected side-effects if you use such classes with tools, such as Hibernate, which expect getters and setters (and constructors) to be plain and simple. I often put some extra code in those methods, because I find it convenient, but quite often funny stuff started happening afterwards, e.g. wrong values being read/saved to the database or getters/setters being executed at inappropriate times, like before the aplication was fully initialized.

If you only use those classes yourself, in a controled way, then it’s ok to have more complex getters/setters/constructors. If they are used by 3rd party bean handling tools, then you can still make them complex, but you have to be careful with what you do. You have to be aware that those tools expect these methods to be simple and that they can call them anyhow, at any time.

]]> By: Tony Marston http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-113 Tony Marston Fri, 30 Jun 2006 13:20:26 +0000 http://new-site.nutrun.com/?p=30#comment-113 Although I do not use Java (I use PHP or all my web work) I decided not t use getters and setters from day 1. Rather than inserting or etracting values one field at a time I do it en mass via an associative array. This means I have have generic methods such as: $array = $object->getData($where); $array = $object->insertRecord($array); $array = $object->updateRecord($array); $array = $object->deleteRecord($where); All these calls are inside page controllers, and as no object names or field names are hard-coded I do not need a separate customised controller for each model. This means I can make use of a standard set of reusable controllers where the class name(s) from which the objects are instantiated are passed in as parameters. I would not e able to achieve the same level of code resuse with getters and setters, therefore getters and setters are evil. Although I do not use Java (I use PHP or all my web work) I decided not t use getters and setters from day 1. Rather than inserting or etracting values one field at a time I do it en mass via an associative array. This means I have have generic methods such as:

$array = $object->getData($where);

$array = $object->insertRecord($array);

$array = $object->updateRecord($array);

$array = $object->deleteRecord($where);

All these calls are inside page controllers, and as no object names or field names are hard-coded I do not need a separate customised controller for each model. This means I can make use of a standard set of reusable controllers where the class name(s) from which the objects are instantiated are passed in as parameters.

I would not e able to achieve the same level of code resuse with getters and setters, therefore getters and setters are evil.

]]> By: Eddy Young http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-112 Eddy Young Fri, 30 Jun 2006 12:49:09 +0000 http://new-site.nutrun.com/?p=30#comment-112 Isn't it "wrong" to use a getter to execute logic code more complex than a simple fetching of a property value? Isn’t it “wrong” to use a getter to execute logic code more complex than a simple fetching of a property value?

]]> By: James Law http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-109 James Law Thu, 29 Jun 2006 23:15:01 +0000 http://new-site.nutrun.com/?p=30#comment-109 Hey, I agree the whole requirment of get/set stinks. FYI, in hibernate, you do not actually need them. Just use access="field" instead of property. One down, 3 frameworks to go though. One thing my teams do since we hate struts actions, is 1. use dispatch action 2. move almost all logic into the form- typical actions can then be about 3-4 lines: 1. cast form 2. have form do something 3. choose view Cheers James Hey, I agree the whole requirment of get/set stinks. FYI, in hibernate, you do not actually need them. Just use access=”field” instead of property.

One down, 3 frameworks to go though.

One thing my teams do since we hate struts actions, is
1. use dispatch action
2. move almost all logic into the form- typical actions can then be about 3-4 lines:
1. cast form
2. have form do something
3. choose view

Cheers
James

]]> By: Tom http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-111 Tom Thu, 29 Jun 2006 15:26:45 +0000 http://new-site.nutrun.com/?p=30#comment-111 I've almost always felt pain when doing fancy stuff in getters and setters. (And that's actually a reason that I'm not too opposed to public fields, especially for non-exported code which you can auto-refactor into getters and setters if needed.) No examples off the top of my head. If I needed to decompose an execute() method, I'd probably prefer to do just that. Make helper methods or classes that do subtasks. I prefer to have all the data ready and then start working with it rather than try to get too fancy with half-finished data or whatever. But I guess, as you said, the post isn't about actions. I just prefer anemic domain models most of the time. I’ve almost always felt pain when doing fancy stuff in getters and setters. (And that’s actually a reason that I’m not too opposed to public fields, especially for non-exported code which you can auto-refactor into getters and setters if needed.) No examples off the top of my head. If I needed to decompose an execute() method, I’d probably prefer to do just that. Make helper methods or classes that do subtasks.

I prefer to have all the data ready and then start working with it rather than try to get too fancy with half-finished data or whatever. But I guess, as you said, the post isn’t about actions.

I just prefer anemic domain models most of the time.

]]> By: Paul (the dude) http://nutrun.com/weblog/the-getter-the-setter-the-thinking-and-the-box/#comment-110 Paul (the dude) Thu, 29 Jun 2006 07:27:25 +0000 http://new-site.nutrun.com/?p=30#comment-110 Sometimes yes, myself in general, no :) Sometimes yes, myself in general, no :)

]]>