General Java - Stop using Getters/Setters when you don't need them

Stumbled across this article: http://typicalprogrammer.com/?p=23

Thought it might be a good read for those of us that are fairly new to Java, I know I learned a bit from that.

 

I'll take a look at it, but I don't really think this belongs in plugin dev. Well, maybe it does now that I think about it.

 

I posted it because I think a lot of people use getters/setters instead of properly protecting their variables with java's built-in controls. It seems like a lot of people just hit generate getter/setter and let Eclipse/Netbeans/Insert IDE here do that for them instead of thinking twice about what they are doing.

by the way: Using a public/protected variable instead of an accessor (getter) is nearly 2x more efficient during runtime (run a test!). I don't mean to say that you should never use getters. But for most plugin developers they should probably think twice before letting eclipse auto-generate them.

 

I can certainly see where they're coming from, as I do use protected variables quite often, however I feel that access methods are implanted so deep into my brain that I wouldn't be able to stop using them.

Not to mention, accessor methods just seem to be easier to read/understand in code, as opposed to referencing protected variables directly. This is just a personal preference, however.

As for the efficiency increase...while it may be 2x as much, its essentially multiplying 0 by 2. The difference is there, yes...but accessor methods do not cause significant stress (even if you were to use hundreds).

Granted, in professional programming, you obviously would have to code differently. However, this is plugin programming, so when it comes to things such as decomposition/reducing of accessor methods/proper documentation...they're not nearly as important (though they are certainly encouraged)

 

@DrBoweNur You really hit the nail on the head with this one. Although accessors are highly inefficient, removing as many as I can in a 30kb plugin quite frankly is like "multiplying 0 by 2".

 

This is not what the article is talking about. This article is not encouraging you to use public variables rather than getters and setters. It's actually encouraging you to create proper "verb" methods that act on your object, rather than getters and setters that act on your object's members. It also seems to be largely directed at Python developers.

 

@nisovin I completely agree with the "directed at Python developers." part, however I still think that this applies to Java devs as well.

 

While it does refer to python, it is overall about programming methods in general. Here's a question for you all: Why would you use a getter on an immutable primitive/object instead of just referencing it directly? (Not talking about API here, I realize getters are useful if you need to change how your accessor operates inside of an API in the future).

 

Just wanted to mention that the public interface of a class should almost never expose an instance variable, and rarely a class variable. It's common practice to use accessors (getters) and mutators (setters), since you can change their implementation without breaking client code. Anything field with default access is generally not considered part of the public interface; protected fields may or may not be, depending.

 

Let's say you have a class called 'Account'. It's got a field called 'balance'. You shouldn't create a setBalance() method. Instead, you should have methods such as addToBalance(), subtractFromBalance(), applyInterest(), etc. You'd probably want a getBalance() method in this situation, but perhaps not in others. In any case, you wouldn't expose the 'balance' field directly. You'd create a method to access it, because what if at some point in the future you need to change the way the balance is obtained? If you used the 'balance' field directly, you'd have to change every point in the code it was used. If you used the getBalance() method, you can just change that method, and the rest of your code will continue to function.

That's the kind of thing this article is talking about.

 

Right. You wouldn't have getBalance either though. You would have something like displayAccountInformation(CommandSender). However, if you're using the eBeans layer for persistence, you must provide accessors and mutators so it can map the database entity into a java object, and vice versa.

 

I think that would depend on your preferred coding patterns. I don't claim to be an expert on these things, but I believe if you're following MVC, the Account class would be part of the model, so it wouldn't have a displayAccountInformation() method, as that would be part of the view.

 

Possible, yes.

Following MVC in, say, a user interface, the Account class would have something more like populateInterface(AccountUI), where AccountUI was an interface implemented by your GUI component, the View. It would also need to subscribe for events it cared around.

Generally, the domain objects for your DAO layer will be wholly separate and sometimes seemingly duplicated in your MVC framework. Sometimes they're merged together to reduce complexity, but that creates coupling that can sometimes be undesirable.

 

I specifically asked about when not dealing with API, why does everyone keep coming back to API examples? Plugins - unless they are specifically designing to be hooked by other plugins wont be providing this type of an implementation, so why would you use getters/setters internal to your own code when you can use protected variables?

Example -> when making a Configuration class I see a lot of people use private static int foo; and then write a getter/setter for the variable. Honestly I'm wondering for things like this, why you would want to use a getter/setter. if you handle it 100% why not make it public/protected.. These types of variables are never designed to be grabbed by other plugins anyway.

 

@nisovin Thank you for letting what the article was talk about sink in. I completely agree with your bank account example where you have accessors, but not just the automatically created getters and setters.

@Sleaker I know you don't want to deal with the API, but you are in the Bukkit Programming Help Forum, so deal with it. I think obsessive getter/setter "abuse" has become very prominent in the bukkit community, and especially with new programmers, simply because 95% of what you do with bukkit is with getters, and occasionally setters. I completely understand that Bukkit is designed to be hooked by other plugins so it needs lots of getters and setters from plugin debs to work with. However, people that are new to programming and bukkit in general take this as a "Oh! Bukkit basically only uses getters and setters, I should too!".

 

These aren't necessarily API examples. These are just good OOP coding standards. It's called encapsulation. Classes should be programmed so that other classes don't need to know the internal workings of the class. This way, if the internal workings of a class need to change, you can effect that change, and the rest of your code will not be affected. There are definitely valid reasons for not exposing class fields, even within your own project.

What if you decide at some point that the value you are setting needs to be manipulated in some way as it's being set? If you've accessed it directly, you'd have to change it in every place in your code you've accessed it. If you've used proper OOP styles, you can just change the code within the class and the rest of your code continues to work fine.

 

As @nisovin pointed out, this has nothing to do with API; it has to do with principles of proper OOP.

The reason you use accessors and mutators is because you may change the implementation of your class without affecting the classes that use it. That said, if the only code that uses the variable is local to a class, it should be declared private; if the only code that uses the variable is local to the package, it may be reasonable to declare it package private.

We're not necessarily talking about other plug-ins. We're talking about other classes within the same plug-in as well. The fundamental discipline of OOP is not so much how external system relate to one another, although that does come into play, but how individual objects relate to each other, often within a single system.

Following strong OOP discipline, especially design patterns, can produce code that's easier to understand, easier to maintain, easier to update, easier to debug, and easier to fork -- if that ever becomes necessary. That is not to say there are no drawbacks, but the benefits are many and "Premature optimization is the root of all evil."

 

Thanks for the responses, by the way guys. still learning a lot here

 

@Sleaker all of us are

 

This. @Sleaker This really comes into play with your own projects when you leave them for a while and come back. As you questioned earlier about why do this if it's all 100% under your control, the future maintainability is a huge consideration.

When I first started as a novice programmer I made a lot of bad decisions in code design; things like not putting in comments, doing cryptic things with code lines that, while they looked cool and took up very little space, were not easy to understand when reading; not using proper accessors and mutators, etc. Let me tell you, when I came back to some of those projects months or, in a few instances, years later to make some modification or other it was nearly impossible due to the various bad design issues.

It's significantly easier to maintain stuff even in your own code if you've been able to follow good OOP design.

As to your particular question about "private static final int FOO = 1;" or similar, I generally will make static finals public if they're something that is intended to be used by other classes, but often I use private as a means to remind myself that other classes really shouldn't be accessing that constant, and if they need to, to rethink the design a bit. If you're referring to just statics without them being final, that I'm not sure. I'd probably have to look at the individual cases to see what they were doing and why.