How to access a protected attribute of a package in another package?

Asked

Viewed 185 times

2

I have the animal pack with two attributes: name and rating. 

    package heranca;

        public class Animal{
            protected String nome = "Leão";
            protected String tipo= "Mamífero";
    } 
      ...

And I have another test package that tries to access the attributes of Animal:

package Teste;

    import heranca.Animal;

    public class main extends Animal{
        public static void main(String[] args){
        Animal animal = new Animal();
        animal.... //como acessar o atributo nome aqui? já tentei criando um novo objeto mas não da certo..
        }

How to directly access the name or type attribute? I know that the ideal is to use a getter, but for didactic reasons I want to access directly via inheritance.

java oop protected

  • As far as I know, an attribute protected can only be accessed by your class, a sub class or by your package (and not otherwise)

  • Well, in my researches I saw that the one you mentioned is the default, already protected is equal to default with the advantage of being able to access in another package through inheritance

  • Take a look in that question about the modifiers and the links mentioned, maybe it helps

1 answer

4


Your concept is all wrong. You’re using inheritance where you shouldn’t and in a way you shouldn’t. The first learning is that inheritance is abused and people inherit what they shouldn’t, and that composition gets better. And if you’re going to inherit see if you’re following the liskov principle.

Another conceptual problem is that packages have nothing to do with the problem, circumstantially another package is involved, but this is not the issue.

This example should have no inheritance and therefore should not have a field (and not attribute) protected being accessed.

Here is another important question: almost every time creating a protected field is doing something wrong. It’s either implementation detail and it should be private, or it’s something that’s part of the contract and it’s public. There are rare cases that should be an implementation detail shared by the subclass, and usually occurs by optimizations.

There is another point that I raise that is about the use of artificial examples. This kind of didactic technique has destroyed people’s understanding on many subjects, and as it is abused in object orientation, almost no one learns OOP correctly, and causes more damage than benefit.

This case shouldn’t have protected fields, so it’s pretty bad as an example. By posting these fields should be public and point, problem solved. Their choice to be protected is that it is wrong.

If you are creating, for example a Girafa starting from Animal would have to justify a field being protected. Tipo it seems very wrong because he should already be part of the hierarchy. Nome maybe it makes sense, but I have doubts. Why should a specific animal have to make use of the name? Maybe, but I believe that nome should be a public field. Or if you prefer to leave it private and only access it by public methods, it would still be accessed by the inherited class.

One last thing I always say: OOP is harder than it looks and if I don’t master its use, better not use it. And try to make it as simple as possible, and just use things that you can justify. Normally use the pattern until other visibility is needed. In your example it has become necessary to be public, so switch to it.

And if you are learning the mechanism to see where to use it, it is a bad didactic. When you have a problem try to find out what the proper mechanism is. Or learn in a structured way where someone experienced gives the problem and the mechanism that solves it well thought out. Unfortunately even books have failed at this when it comes to OOP, imagine blogs, tutorials without compromise or videos on the internet.

Browser other questions tagged java oop protected

You are not signed in. Login or sign up in order to post.