You don't hear much about it, but I think its worth consideration. There is such a thing as the "uniform access principle." Which basically says that there is benefit accessing things in your object the same way. i.e. always get to something via. a function.
It doesn't seem like a big deal, but if you're used to it, and then suddenly you find yourself in a code base where they mix styles, e.g. some things are accessed via. methods and some are accessed as member vars and you find yourself frequently having to check whether or not attribute X is accessed directly or through a method you begin to appreciate it. At least, this was the case for me. So taking a large java code base and starting to switch to member access could create cognitive baggage for future maintainers I think though that properties v.s. members v.s. accessors isn't really the right question. If you have something that is essentially a data bag, is an object the right place for it? I think that the case is made for a more functional style pretty well here: http://blog.objectmentor.com/articles/2009/04/20/is-the-supremacy-of-object-oriented-programming-over I guess I have always felt that in general objects can be overkill for *just* data. And I'll be honest, a lot of what I have done over the years is sloughing *just* data around. Why bother with objects/ members or properties for things that are basically data bags? Certainly there are times when its more than just data, and then objects are great. If only we had some sort of hybrid oo/functional language... Arrrgh! On Jul 1, 2:07 pm, MassH <massimohei...@gmail.com> wrote: > This issue has come up dozens of times. > > First, it's clearly absurd to fill source code with boilerplate getter/ > setter code. Even if IDEs can auto-generate, it still has to be > manually read/maintained. > > What I don't understand is why language changes are needed to avoid > that. > > Libraries and frameworks like JPA/Facelets/Spring/etc should use > explicit getter/setter methods if they exist and otherwise fallback on > raw exposed instance variables. Some Java libraries already do that. > > That way for the 99% case, you just use a plain instance variable and > for the 1% case where you need non-trivial getter/setter logic you can > write them. Also, you can change your code at any time without > breaking compatibility. > > class SomeClass { > // No getters/setters. Libraries like JPA/Facelets/Spring/etc can > // access directly in the absence of getters/setters > public int simpleProperty; > > // Example where explicit getter/setter logic is actually needed. > private int complicatedProperty; > public int getComplicatedProperty() { > // Do something non-trivial > } > public void setComplicatedProperty(int value) { > // Do something non-trivial > } > > } > > BTW, JavaFX has a very elegant solution to the issue with binding. > > Also, great Cay Horstmann interview --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
