I don't mean to imply that they're bad. I do think though, that it can just be a bit heavyweight. Also (as better stated in the blog I linked to) I also think that its hard to balance competing group's needs in an object model.
HashCode & equals aren't bad either these days because I can generate them in netbeans. I agree with you too about memory. I don't think that's a concern in most environments, maybe on something like a phone though it could be an issue. On Jul 1, 3:36 pm, Alexey Zinger <[email protected]> wrote: > Why are objects bad for passing data around? I'd agree that writing a new > class and implementing hashCode and equals for every kind of data structure > by hand is no fun. But, thanks for certain ORM approaches on one hand and > strongly typed (generified) tuples (even pairs) gets us a long way toward > that goal. If you think about how objects actually behave in terms of memory > utilization and access speed, it's really not that bad. > > Alexey > > ________________________________ > From: Bill Robertson <[email protected]> > To: The Java Posse <[email protected]> > Sent: Wednesday, July 1, 2009 3:06:47 PM > Subject: [The Java Posse] Re: Java Properties > > 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-... > > 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
