Earlier quoted context omitted.
Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.
That examples makes sense, but what about Strings and other types? I'm not sure you can do the same thing for a User object with name, age etc. I'd love to not have getters/setters but I have yet to see a replacement for all get/set scenarios.
Java 9 features announced
151–160 of 228 posts
Re: Java 9 features announced
#152Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
// Sorry if there are any mistakes, I have not
// written any Java code for quite some time.
public class Point
{
private int x;
private int y;
.
.
public int getX()
{
return x;
}
public int getY()
{
return y;
}
public void setX(int newX)
{
x = newX;
}
public void setY(int newY)
{
y = newY;
}
}
Look at how long the class definition is for something so basic!In Common Lisp there are two ways to define classes/structures, defstruct and defclass. Defstruct[0] automatically automatically defines everything for you:
(defstruct point x y)
will define the procedures make-point, point-x, point-y, (setf point-x), and (setf point-y). The cool thing is that they are all procedures. It easily change the class definition without changing the code that uses it. There are also some additional options for defstruct to specify default values, how to print the structure, as well as what prefix to use (the default is the name of the structure, 'point' in this case).Defclass[1], while much more verbose than defstruct, is much more powerful:
(defclass point ()
(x :writer set-x :initarg :x)
(y :reader get-y :initarg :y)
(z :accessor z))
will define procedures, set-x, get-y, z, and (setf z). Set-x and (setf z) are the setters, while get-x and z are the getters. To construct a point that is defined this way, one has to use the procedure make-instance which will take keyword parameters[2] :x and :y, for x and y respectively. [0] http://www.lispworks.com/documentation/lw445/CLHS/Body/m_defstr.htm
[1] http://clhs.lisp.se/Body/m_defcla.htm
[2] http://www.gigamonkeys.com/book/functions.htmlRe: Java 9 features announced
#153Earlier quoted context omitted.
Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?
IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…
Re: Java 9 features announced
#154Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.
Why not just declaring the fields public and access them directly? Is there anything I am missing?
Also, it breaks encapsulation, because your internal storage should be changeable without ruining your external surface area.
Re: Java 9 features announced
#155> improved support for multi-gigabyte heaps I've heard this thrown around before, but what this actually mean? Is it just some optimizations to the garbage collector?
And see also: https://bugs.openjdk.java.net/issues/?jql=project%20in%20(JD...
Re: Java 9 features announced
#156Earlier quoted context omitted.
Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested. For example, with protocol buffers you end up doing things like. AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build(); Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build(); Pref…
This seems like a perfect example of a pattern applied in the wrong way. The builder pattern is supposed to be used to construct new instances (in other languages named parameters make it pretty redundant). I could perhaps understand allowing people to batch up changes but when you're forced to switch to a builder and back again to make a change to one field you've definitely got a poor design. The example seems part…
You are right that normally you'd want the addFavourite method but in his example he is dealing with generated code which has a tendency towards verbosity.
You could add the method if Java allowed extension methods...
Re: Java 9 features announced
#157Earlier quoted context omitted.
> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. Others have noted that in many contexts in C# there is a difference, so clients do need to know. As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal ca…
> Others have noted that in many contexts in C# there is a difference, so clients do need to know. Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code. public int Foo { get; set; }
public int Foo { get; private set; }Re: Java 9 features announced
#158Earlier quoted context omitted.
It seems that it is almost in prototyping stage, the usual suspects have already written a sketch of a future proposal: http://cr.openjdk.java.net/~jrose/values/values.html
Awesome! Thanks. I don't know much about the path from idea to standardized feature with the JVM. Is there hope for it in Java 9 or is this much farther out in the future? Probably first and more importantly, what is the chance for this even ever happening?
Re: Java 9 features announced
#159The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.
Re: Java 9 features announced
#160Earlier quoted context omitted.
It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…
I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…
class Foo(object):
def __init__(self, bar):
self._bar = bar
@property
def bar(self):
return self._bar
@bar.setter
def bar(self, value):
self._bar = value