1 Getters and Setters are NOT Evil {anchor:Getters and Setters are NOT Evil} I was just reading Martin Fowler’s blog entry on {link:Getter Eradication|http://martinfowler.com/bliki/GetterEradicator.html}, in which he mentions Allen Holub’s article entitled {link:"Why getter and setter methods are evil"|http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html}. This reminded me of an email I wrote to a friend on the same subject a couple years ago. It's still relevant so here's what I said: One of Mr. Holub’s beliefs is that "getters and setters are evil". He argues that providing getters and setters breaks an Object’s encapsulation. Instead, he argues, you should just ask the Object to directly do for itself whatever it is that you want to do with it. For example: instead of writing a GUI control for editing a User (which would require getters and setters), you should ask the User to provide a GUI control for itself: ie. getGUI(). The problem with this is that while it looks nice for toy examples, it doesn’t scale. What happens if you want an Object to have a Swing GUI, a Web Interface, a WAP Interface, and a PDA GUI? Now how about some conversion methods for XML, CSV, JDBC, and other formats? You would end up with a super large Bean which wouldn’t be unusable anywhere. You couldn’t run it on a PDA because the PDA wouldn’t have Swing, you couldn’t use it in a desktop app because it wouldn’t have Web/Servlet libraries, you couldn’t run it on your server because it wouldn’t have your PDA UI libraries, and so on and so on. You have extreme tight-coupling and horrible containment (you only need one thing but as a result end up bringing in everything else). If you aren’t the author of an Object then you can’t do anything with it other than what the author thought you should be able to do with it. Imagine if every new use of User across any application required us to issue a new version of the Framework to add the extra support to User. Another problem is that it becomes difficult to implement features that involve more than one Object? Which Class gets the method? How does it get what it needs from the other class? The equals() method is a simple example. This approach only work in specific, single-tiered, closed systems where all requirements are initially known and there is no reuse or desire for extensibility. 2006-03-23 16:10:32.638 2006-03-23 16:10:32.638 http://www.strangepersons.com/images/content/8531.jpg 2006-03-23 17:00:02.126 2006-03-23 17:00:02.044 Indeed, as manero says, this subject has come up before. See {link:here|http://www.javablogs.com/Search.action?query=getters} and {link:here|http://www.google.com/search?q=getters+and+setters+are+evil}. 2006-03-24 22:31:16.279 2006-03-23 19:19:09.537