For my assignment my professor has given me the option of either accessing the private attributes of an inner class directly, or making my own "set" methods for those attributes.

I am not sure what is generally considered best in this case. I am not used to accessing private attributes directly, but I'm new to Java, and haven't used inner classes much before either. 

She's not going to take off points no matter what I do, so I hope this isn't considered, "homework help".

Anyway, which do you feel would be best and/or most elegant?

At the class room level it really does not matter IMO, both solutions would be equal (so I would go with the one that is more readable). The reason I would use a set/get method is if in case I decided later that I needed some extra processing done whenever I set or get a given variable, I could just throw it in the method. And you can think of an inner class as just a folder within a folder. The parent class is the outer most folder, and the inner class is the inside the outer folder. Each folder has it's own variables, methods, classes, etc.In the end it's all just storage.

17 hours ago, mrpeed said:

At the class room level it really does not matter IMO, both solutions would be equal (so I would go with the one that is more readable). The reason I would use a set/get method is if in case I decided later that I needed some extra processing done whenever I set or get a given variable, I could just throw it in the method.

Thanks! So, I guess you prefer using a method?

Asking for opinions is perhaps not the most useful approach. You can get basically any answer you want, since everybody has a different opinion. There is no universal agreement on how to write code. (I, for one, would not write getters and setters unless they are actually useful today. For private members I sincerely doubt it is ever useful.)

You verified whether it makes any difference, and it doesn't. This means you can basically do whatever you want without any consequence. My suggestion to you is to form an opinion of your own about it. Code both (the difference isn't that large), leave both solutions alone for a few days, and then look at both again. Which one appeals most to you and why?

15 hours ago, Alberth said:

Asking for opinions is perhaps not the most useful approach. You can get basically any answer you want, since everybody has a different opinion. There is no universal agreement on how to write code. (I, for one, would not write getters and setters unless they are actually useful today. For private members I sincerely doubt it is ever useful.)

You verified whether it makes any difference, and it doesn't. This means you can basically do whatever you want without any consequence. My suggestion to you is to form an opinion of your own about it. Code both (the difference isn't that large), leave both solutions alone for a few days, and then look at both again. Which one appeals most to you and why?

 

Well, I was hoping to use other people's opinions to help form my own. I don't think it's a big deal either way, I was just curious. I think I'll go with methods just because it seems somehow more right to me to use methods to access private attributes. Do you say getters/setters for private methods aren't useful because they're unnecessary?

@Alberth great answer.  

@RidiculousName My personal opinion on the matter is that if you're going to compare the following:

x = 5;

or

public void setX(int x) { this.x = x; }

You have no real difference at face value but people will argue that this "protects" the variable from being changed. This really isn't true because you can still call the set method and fill x with any value. I'm a strong believer in doing what you need when it's required, and not simply following a "style" or "approach" because people tell you it 'should' be done like that. In my professional work I use JAVA only for android related stuff so it doesn't take up the majority of the programming I actually do. I have noticed that in JAVA it seems to be taught a lot more heavily as best practice to only used Set and Get methods when dealing with member variables. I guess it has to do with encapsulation. Do I personally use this approach? Yes and no... I will explain why.

If I only need to edit the variable without any additional steps then I wont bother. I have seen people flood their code with the following for every single member variable:

public void setX(int x) { this.x = x; }
public int getX() { return this.x; }

Now if I need to make a set for something like 'health', then I might do this because I can add in additional checks

public void setHP(int hp) {
  if (hp > 0) {
    this.hp = hp; 

      if (this.hp > this.maxHp) {

      this.hp = this.maxHp;

      }
  }
}

Some advantages to having Set is that you can always go back in add additional validation if needed, but in my experience I design everything the best way from the start not requiring me to go back and add in additional checks.

Some people will use Get methods if they are wanting to retrieve something and that variable will never be edited either through a set method or directly and just helps prevent accidental editing.

What I personally do is use a setter if I need to add validation. I rarely use getters (unless I have to) as I don't recall anytime I ever accidentally modified a variable when asking to retrieve its value. If I'm working on a project quickly I find it faster to just work directly with the member variable unless I need validation.

At the end of the day it comes down to using what makes sense for the task at hand. Regardless, the beauty in programming is that you can achieve the same result in different ways.  

19 hours ago, RidiculousName said:

Do you say getters/setters for private methods aren't useful because they're unnecessary?

In my view, the first reason why you'd want to have a getter or setter is if you provide code as a library, which is used by other people. If you allow access directly to the variable from the library code, you cannot change that variable when updating the library, since it's part of the interface contract between you and whoever uses your library. A getter or setter however can contain any code you like, the access stays the same. Thus the getter/setter achieves a decoupling between library internals and external access. Your users won't be affected from code changes in your library.

A second but quite closely related second reason is the interface class. You cannot express presence of a variable in an interface, while presence of setters and getters can be expressed. This causes a need for getters and setters even if they don't actually protect anything. I mostly consider this a design flaw in the interface, although an understandable one, given the protective nanny nature of the language.

For private variables both cases don't hold. The scope of the variables is private, ie only code literally in the same file can access them. This also voids any decoupling advantages, as to change either the variables or the getter/setters, you have to modify the exact same file. Refactoring a setter/getter in at a later time, is not more difficult then doing it early, since it's still all in one file.

However, in the end, it's mostly how you feel about variables being "owned" by an object. If you feel that strongly, you're more motivated to protect it heavily (guard dogs, barb-wire, and armed check-points). I am coming from a C/Python background which assumes that all code behaves, and lives happily together working as a team to that goal of working code. (Peeking into other variables is fine, changing your neighbour internals is not (unless explicitly allowed), so you just don't do it.)  Totally different world view between both languages!!