On Sat, 25 Aug 2007, Eelco Hillenius wrote: > are discussing here though is quite a different case. If it is no > problem that people access members directly, and you think getters and > setters are too much bloat, why don't you just make them public then?
Because it's less future proof in the current version of Java. In a framework, it's easy to try both via accessor method and direct field access, but in normal Java code working with these same objects you really have to pick one or the other. In Ruby (and I think that in some future version of Java), the syntax of addressing a property could be the same regardless of whether it goes directly to the field or via the accessor method, but in Java 6 and below you have to choose they way to access the property explicitly. So if you suddenly want to add special handling when accessing a field it's not so easy to make the field private, add the accessor method _and_ not need to touch the rest of the code. (Well, I remember having seen an "encapsulate fields" refactoring in some IDE, but didn't try it yet to see if it corrects all field access in calling code as well, and this wouldn't anyway work with external code.) It's not the first time this poor horse gets flogged http://www.artima.com/forums/flat.jsp?forum=106&thread=36312 > that is supported by most if not all EL out there. But having private > members without getters and setters but saying they should be easily > accessible by the outside world is kind of a double standard. I don't think so. If Wicket had a way of populating the domain objects via their constructor, say with named (constructor) parameters (which were being planned for some future version of Java I think?), it might be. There are similarities between different edges of the system, whether it be data access or UI layer. One such issue is that often there is need to access the data of a domain object in ways that are not necessary in domain logic code. Maybe we should have "friend" visibility in Java too ;) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oy <URL: http://www.ri.fi/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
