Java style question getter / setter

Question

I have a question about Java style. I have been programming Java for many years, but primarily for my purposes, where I didn’t have to worry much about style, but I just don’t have a job where I have to use it professionally. I ask because I am going to have people really look at my code for the first time, and I want to look like I know what I'm doing. Heh.

I am developing a library that other people will use in my work. The way other code will use my library is to create an instance of the main class and possibly call a method or two in it. They will not need to use any of my data structures or any of the classes that I use in the background so that everything is done. I will probably be the main person who supports this library, but other people will probably sometimes look at the code.

So, when I wrote this library, I just used the default access level for the modifier for most of my fields and even got to the point where other classes sometimes read and maybe write from / to these fields directly. Since this is in my package, it looked like an “OK” way to do something, given that these fields would not be visible outside the package, and it seemed that it was not necessary to make things private and provide getters and setters. No one except me will write code inside my package, this is a closed source, etc.

My question is: will this look like a bad style for other Java programmers? Do I have to provide getters and setters even when I know for sure that I will receive and set fields, and I don’t worry that someone else writes something that breaks my code?

Answer 1

I would really not like to analyze the code with anything other than private fields, with the possible exception of a protected field in the interests of the subclass. This will not help you look good.

Of course, I think that from the point of view of a Java expert, you can justify a deviation from the style, but since this is your first professional job using Java, you are not really in that position.

So, to answer your question directly: "Will it look like a bad style?" Yes it will.

Was your decision reasonable? Only if you are really sure that this code will not go anywhere. In a typical store, there may be chances to reuse the code, expose factors to utility classes, etc. This code will not be a candidate without significant changes. Some of these changes can be automated using the IDE and are mostly low risk, but if your library is at a point where it is stable, tested and used in production, encapsulation, which will later be considered a greater risk than necessary .

Answer 2

Even in your closed source package, encapsulation is a good idea.

Imagine that a class group in your package refers to a specific property, and you understand that you need to, say, cache this property or register all access to it or switch from the actual stored value to the value that you generate on the fly. You will have to change many classes that really should not change. You expose the inner workings of a class to other classes that do not need to know about those internal processes.

Answer 3

I would adhere to the general style (and in this case provided setters / getters). Why?

• This is good practice when you work with other people or provide libraries for third parties.
• many Java frameworks assume recipient / setter agreements and have the ability to search for / expose / poll them. If you do not, your Java objects will be closed from these frameworks and libraries.
• If you use setters / getters, you can easily reorganize what's behind them. Just using fields directly limits your ability to do this.

It is truly tempting to use the “just for me” approach, but there are many conventions as the material uses them and / or is good practice for some reason. I will try to fulfill them as much as possible.

Answer 4

I do not think that a good language should have ANY level of access, except for a private one - I am not sure that I see any benefit.

On the other hand, also be careful with getters and setters - they have many pitfalls:

• They tend to encourage poor OO design (usually you want to ask your object to do something for you, rather than acting on its attributes).
• This poor OO design causes the code associated with your object to spread around different objects and often leads to duplication.
• settings make your object volatile (which is always nice to avoid if you can)
• setters and receivers expose your internal structures (if you have a getter for int, it is difficult to change it to double later - you need to touch every place that it was addressed to and make sure that it can handle double without overflow / causing an error, if you just asked your object to manipulate the value first, the only changes would be internal to your object.

Answer 5

Most Java developers prefer to see getters and setters.

No one can develop the code in your package, but others consume it. By providing an explicitly open interface, you can guarantee that external consumers will use your interface as you expect.

If you publicly publish an internal implementation of a class:

• Unable to prevent users from misusing the class
• Lose control over entry / exit points; any public field can be changed at any time
• Increase the relationship between internal sales and external customers

Maintaining getters and setters can take a little longer, but offers much more security plus:

• You can reorganize your code at any time as necessary, as long as you do not violate the public API (getters, seters and public methods).
• Group testing of well-encapsulated classes is simpler - you check the open interface and that it (only your inputs / outputs in the "black box")
• Inheritance, layout, and interface design will all make sense and will be easier to develop with decoupled classes
• Decide if you need to add some check on the mutator before installing it? One good place is inside the setter.

It is up to you to decide whether to take advantage of the added time.

Answer 6

I would not care about the style (or any dogma in this regard), but the maintainability that comes with the set of getter / setter methods. If you (or someone else) needed it later to change the behavior associated with changing one of these attributes (write down the changes, make it thread safe, misinform the input, etc.), but already changed them in a lot of other places in in your code, you would want you to use the getter and setter methods.

Answer 7

Since you're the only one writing code in your closed source package / library, I don't think you should worry too much about style - just do what works best for you.

However, for me, I try to avoid direct access to the fields, because it can make the code more difficult to maintain and read - even if I'm the only maintainer.

Answer 8

Style is a matter of convention. There is no right answer if he agrees.

I'm not a camel fan, but in the Java world, camel camels are correct, and all member variables must be private.

getData(); setData(int i); 

Follow the official Sun Java code agreement (cough Oracle) and everything should be in order.

http://java.sun.com/docs/codeconv/

Answer 9

To be brief, you said: "I ask because I am going to have people really review my code for the first time, and I want to look like I know what I'm doing." So, change your code because it really looks like you don’t know what you are doing.

The fact that you picked it up shows that you know that this will probably look bad (this is good), and it is. As already mentioned, you are breaking the basics of OO design for expediency. This simply results in fragile and usually unreachable code.

Answer 10

Encapsulation violation is a bad idea. All fields must be closed. Otherwise, the class cannot guarantee that its own invariants are preserved, because some other class may accidentally change the fields in the wrong way.

Having getters and seters for all fields is also a bad idea. The field with getter and setter is almost the same as in the public field - it reveals the details of the implementation of the class and increases the connection. Code that uses these getters and setters easily violates the principles of OO, and the code becomes procedural.

The code must be written so that it follows Tell Do not Ask . You can practice this, for example, by executing Object Calisthenics .

Answer 11

Even if it’s painful, encoding properties with getters and setters is a big win if you ever use your objects in context, for example, in JSP (especially in the expression language), OGNL, or another template language. If your objects follow the good old Bean conventions, then many things will "work" later.

Answer 12

I find getters and seters to be the best way to program, not just a question about coding convention. Nobody knows the future, so we can write a simple phonenumber string today, but tomorrow we may need to put a “-” between the area code and the number, in this case, if we have the getPhonenumber () method, we can make such decorations very easily. Therefore, I would suggest that we should always follow this coding style for better extensibility.

Answer 13

Sometimes I use public final properties without get / setter for short-lived objects that simply carry some data (and will never do anything by design).

Once upon a time, I would really like it if Java meant getters and setters created using the property keyword ...

Answer 14

Using encapsulation is a good idea even for the closed source, which was already mentioned in JacobM. But if your code acts as a library for another application, you cannot stop another application from accessing classes that are defined for internal use. In other words, you cannot (?) Apply the restriction that the public class X can only be used by classes in my application.

Here I like the architecture of the Eclipse plugin, where you can tell which packages in my plugin may depend on plugin connections at runtime. JSR 277, aimed at bringing similar modular functions to the JDK, but now it's dead. More about this here, http://neilbartlett.name/blog/2008/12/08/hope-fear-and-project-jigsaw/

Now the only option is OSGi.