How do I access a protected attribute of a package in another package?

Question

How do I access a protected attribute of a package in another package?

Navigation

#1 by (4 votes)

2

I have the animal package with two attributes: name and classification.

    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 do I directly access the attribute name or type? I know the ideal is to use a getter , but for didactic reasons I want to access directly via inheritance.

java protected

asked by anonymous 02.09.2018 / 19:18

1 answer

How to implement an abstract method with a generic class in C # Lapply does not return the desired result for some functions

score 4 · Accepted Answer

Your concept is all wrong. He is using inheritance where he should not and in a way he should not. The first apprenticeship is that inheritance is abused and people inherit what they should not, and that composition gets better . And if you're going to do it, 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 protected field ( and not attribute ) being accessed .

Here's another important question: almost always creating a protected field is doing something wrong. Either it's implementation detail and it must 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 through optimizations.

There is another point I raise that is about the use of artificial examples. This type of didactic technique has destroyed people's understanding on many subjects, and since it is abused in object orientation, almost no one learns OOP correctly, and does more harm than good.

This case should not have protected fields, so it's very bad as an example. By posted these fields should be public and point, problem solved. Their choice to be protected is that they are wrong.

If you are creating for example, a Girafa starting from Animal would have to justify a field to be protected. Tipo seems very wrong because it should already be part of the hierarchy. Nome might make sense, but I have doubts. Why should a particular animal have to make use of the name? Maybe, but I believe 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 you always talk about: OOP is harder than it looks and if you do not master its use, better not even use it. And try to make it as simple as possible, and just use things you can justify. Usually use the default until other visibility is required. In your example it became necessary to be public, so change to it.

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