Why does java.awt.Dimension have public variables?

Question

Isn't it true that a class with public variables is considered weak in Encapsulation and is it not a bad design practice?

If such is the case why does java.awt.Dimension have 2 public variables width and height ?

Answer 1

I think that exposing public fields is not a violation of encapsulation itself. Encapsulation is the property of entities, that hide inside themself a complex inner structure. This complex structure can't be accessed directly and therefore not being risked to be broken. It is accessed only through public methods, which make their work well and don't corrupt the complex inner structure. For example, we don't have access to HashMap 's hashtable directly and we can't corrupt it. We only use get and put methods, that care of hashtable state properly. But where is the complex structure of Dimension object? What things get broken when we just write d.width = 23 ?

I think there are reasons to use public getters/setters instead of public fields in this case: taste and conventions. The latter is more significant, I suppose. But it also depends on where and for what we apply this conventions.

Answer 2

If you look at the JavaDoc for Dimension: http://docs.oracle.com/javase/7/docs/api/java/awt/Dimension.html

You will see that the public fields have been there since 1.0 (1996). The language has evolved to accomodate many principles and best practices over time to become the language that it is today. This included a reworking of the AWT model for the 1.1 release, of which the accessors and mutators where added for these fields.

Here are some archived release notes for the JDK 1.1 release: http://www.cis.upenn.edu/~bcpierce/courses/629/jdkdocs/guide/awt/HowToUpgrade.html

From which this is quoted:

"These changes make it possible for programs such as GUI builders and JavaBeans-using programs to query components to determine the components' properties."

Answer 3

Dimension has been around for a really long time and in the early days of Java there was a real concern about performance. So they used public variables and made it mutable - two major mistakes, just to gain a few clock cycles.

All you guys asking questions about premature optimizations can learn a good lesson here. (Added)

Dimensions change a lot (as a window is resized) and by making it mutable you "save" on having to allocate new objects - just reuse the old one. Which, in the early days of Java, made some sense. Plus, they got accessed a lot as the GUI drew nested Buttons within Components inside Frames, so, to save a few cycles in a redraw don't use a function call. Again, makes a little sense.

The problem is that nowadays with all the multi-core processors and multi-threaded code you often en up making defensive copies of a Dimension. Losing all that "advntage", plus, annoying and a source of bugs.