1

I come from C++, and actually I haven't really used class inheritance at college yet, so I'm learning by myself. I'll put my doubt in the form of an example:

Let's say I have a class called Entity. This entity class holds two integers representing some X and Y coordinates (this is not relevant, it could be any other field). Then I have my class Player, extending Entity. As it might seem usual, I want Player to use as well the x and y fields, and some code in the Entity class refers to those fields as well.

Now comes my doubt. Are x and y public, private or protected? I feel like they should be protected, as public is not an option (Other classes should'nt be accessing it) and private doesn't allow me to use the x and y fields from the extended (Player) class. But I read elsewhere that class fields should never be protected, only methods.

Other sollutions to this other than setting the variable to protected that come into mind would be using getters and setters from the super class (which in my opinion is not only a bad practice but completely redundant and unnecesary), or re-declaring those attributes in the new class, which let's me thinking if I'm getting any reward from inheritance if I'll have to type all the field declarations twice. I actually don't even know if this last thing might work as I don't know Java that well to know how it handles this visibility issues.

Any help on the topic would be much appreciated.

Thank you.

Setzer22
  • 1,589
  • 2
  • 13
  • 29

4 Answers4

4

[Using getters and setters]... which in my opinion is not only a bad practice but completely redundant and unnecessary

Actually no, this is often considered the best approach. There are a variety of reasons to favor it, ranging from maintainability to security. You would make the fields private, and declare methods in the base class to both access and alter them.

Community
  • 1
  • 1
arshajii
  • 127,459
  • 24
  • 238
  • 287
  • Well, you've got a point, I don't feel like this is redundant anymore, but certainly having to access a method to access a property is slower, unless some low level optimisations which I'm not aware of are being made by the interpreter/JIT compiler... – Setzer22 Jul 24 '13 at 20:43
  • I think the main reason getters and setters are such good practice is that the statement `[class].getX() = y` will not work. of course, you could use a `setX()` method, but only if you create that method. But this way you can control the ability to make changes to fields, which is important if you have something like a public api that you don't want people hacking – scottysseus Jul 24 '13 at 20:43
  • @Setzer22 The time difference between a method call that directly returns a field and accessing the field itself is negligible. You shouldn't worry about such minute optimizations. – arshajii Jul 24 '13 at 21:12
  • This may be offtopic at this point but although [class].getX() = y doesn't work, if X were to be an object with the field "fieldX", doing [class].getX().fieldX = y (Assuming fieldX and y are of the same type, of course) isn't forbidden. And if I don't have access to the implementation of the class there's not much I can do about that. Of course this is the intended behaviour, but I feel doing this gets even messier. Is there a better way to do this? is this even the good way to do this? At least its better than instancing a new Object just to use the setter – Setzer22 Jul 24 '13 at 23:18
  • @Setzer22 I'm not sure I follow; `getX()` should *return* `fieldX`. – arshajii Jul 24 '13 at 23:21
  • Oh, I meant that fieldX was a field inside X, where x is an object, not an integer. – Setzer22 Jul 25 '13 at 00:00
2

if you want variables to be accessible through subclass, you need to make them protected. but still those will be accessible from other classes but in same package. however those will be protected from classes outside of the package, except those who inherit your class where the variables are defined.

And yes, instead of making variables themselves as private, you should define setters to access them. It is not at all bad practice, in fact its best practice in all object oriented programming.

Ankit
  • 6,554
  • 6
  • 49
  • 71
1

It really depends on purpose of the Entity class. If its just holder of x and y - because many of your classess will use them then it's perfectly fine to make them protected.

If there is any logic bound to those coordinates - especialy validation, some event upon change. Then you need to use getters/setters to encapsulate this logic inside Entity class.

Nothing is set in the stone and you can allways reworke this - as long as other developers does not depend on that. If you have other dependent on your code - you have to design more safely. But don't overdesign.

Hurda
  • 4,647
  • 8
  • 35
  • 49
  • I think I see it now. The main problem I have is that I'm using inheritance when it's really not needed, or I don't get that much of a benefit from using it. But anyway, you're right, getters and setters are the way to go when trying to encapsulate functionality that is not in need to be seen, and if i organise well my packages, protected isn't that bad when having simple integer fields which are just holders. Thank you – Setzer22 Jul 24 '13 at 23:40
0

Couldn't you use no access specifier in this case? Using protected (unless I am mistaken) allows all subclasses, including those from different packages, to have access. In most (but not all) cases in which you are just making a little program for yourself, if you want a subclass to have acces to a superclass's variable, you could just have no access specifier.

This picture should give you information about all of the different access specifiers. The 'Package' column refers to subclasses within the same package, and the 'Subclass' column refers to subclasses regardless of package. enter image description here

scottysseus
  • 1,922
  • 3
  • 25
  • 50
  • I thought not using a access specifier in a field made it private by default like in C# or C++, I'll take that into account as well. – Setzer22 Jul 24 '13 at 23:32