O Protected realmente é util?

A todos um bom dia, boa tarde e boa noite. Sou novo aqui no forum, mas já vinha lendo o conteudo desde de muito tempo, ja que muitas das minhas dúvidas eram sanadas só apenas lendo o conteúdo deste e de outros foruns por ai, mas desta vez não encontrei nada referente a uma questão que já faz um tempo que estou observando, mas só se discute a funcionalidade, mas não a utilidade.

Então a pergunta pertinente que tenho é se a funcionalidade do protected é realmente útil?

Pois até agora não vi nenhuma vantagem em usar tal recurso, no caso privado na classe mãe e público nas classes filhas e até hoje não vi uma implementação que mostrasse uma real utilidade deste recurso, já que em todas as csituações um public já resolveria muito bem.

Se ao menos funcionasse como privado na classe mãe e publico apenas dentro das classes filhas, mas privado na instancia, seria legal, no caso o seguinte escopo:

abstract class ClasseMae {

    protected int getSoma(){
         return 2+2;
    }

}

public class ClasseFilha {

    public int getDivisao() {
        return this.getSoma/2;
    }

}

public class Main {

    public static void main(String[] args) {
         ClsseFilha classe = new ClasseFilha();

         // Isto seria possivel
        classe.getDivisao();

         // Mas isso daria erro
        classe.getSoma();
    }
}

Então é sobre isso que gostaria de saber na opnião de vocês, já que muitos aqui tem bem mais tempo e experiência em java e OO do que eu, outra coisa é se existe tal recurso que descriminei acime em Java, pois este é um recurso que sinto muita falta.

Imagine o seguinte

Existe um método que vc cria numa classe só que ele não pode ser acessado pelo usuários, mas vc quer que se alguém quiser extender esse seu objeto ele vai necessitar ter acesso a esse método. Logo o protected tem essa função.
Existe muitos métodos na biblioteca java que são assim.

falow

Correto, mas avalia o seguinte de certa forma está obrigando o desenvolvedor a realizar uma má prática, no caso mal uso da herança ao invés da composição, já que para usar tais recursos teria que herda de qualquer jeito, por que não usar uma classe abstrata? Não resolveria melhor o problema em questão?

Se considerar hoje em dia que herança é algo que deve ser avaliado com cuidado isso de certa não estaria indo contra a maré? Sem contar que a preferenci está mais sobre o uso de composição einterfaces ao invés de herança da herança que só faz inchar ainda mais o componente a ser usado.

Veja o método clone de Object, é um exemplo clássico do uso do protected…

o que vc tem que entender… é que protected, quer dizer que o método é necessario para funcionamento do objeto… e não deve ser acessado fora do escopo do objeto, para evitar problemas…

porem caso deseje-se extender a classe se faz necessario o acesso ao método, pois a funcionalidade do objeto pode depender do uso deste método…

A palavra reservada protected e realmente importante quando se esta programando OO. Pois as vezes é necessário criar classes abstratas, que contenham métodos ou atributos que precisam ser usados somente nas subclasses. Algumas classes abstratas do java possuem métodos abstratos.

Na verdade, o protected não é muito utilizado.
Colocar public no lugar é prejudicial. Quanto mais coisa public você tiver, maior vai ser o seu acoplamento, e possivelmente pior vai ser o seu encapsulamento. O ideal é colocar como public apenas o necessário e nada mais.
Herança de classes é algo considerado ruim para algumas pessoas (inclusive eu). Logo, se você não tiver herança, protected é algo que não tem sentido.
Mas, se você tiver herança, o protected, apesar de pouco usado, é muito importante. Ao deixar um método ou atributo público ele fica exposto e o seu projeto fica mais amarrado. Usar private deixa ela completamente desamarrada, mas não é possível criar algo que faça sentido sendo completamente privado. Usar protected no lugar de public deixa a sua classe mais desamarrada para futuras mudanças, algo como “parcialmente privado”.

Na verdade os metodos proporcionam um baixo acoplamento, vcs estão confundindo as coisas, um metodo é uma chamada a uma determinada camada de código, pra quem chama não importa o que ele faz, então tecnicamente, se vc alterar a implementação do metodo (não os argumentos, nem os retornos), para quem usa esse metodo ainda vai continuar como se nada tivesse mudado.

Qual a vantagem de se usar uma linguagem OO se não utilizar o principio basico da OO a herança? quer queira quer não vc esta usando herança em todo o java (java.lang.Object).

Agora ao tópico.

O protected é quase como se vc disse assim, ninguem acessa, somente os meus filhos podem. E quase como a geladeira de casa (nem sempre). E ele é muito util, principalmente quando se trabalha em equipe, e não quer que uma chamada a um metodo que venha de fora prejudique o funcionamento da sua classe. Somente as filhas podem alterar, ai vc pode encapsular tudo. Eu uso bastante protected em campos que quero que esteja disponiveis para as filhas, uso ele pouco em metodos.

[]'s

[quote=Felagund]Na verdade os metodos proporcionam um baixo acoplamento, vcs estão confundindo as coisas, um metodo é uma chamada a uma determinada camada de código, pra quem chama não importa o que ele faz, então tecnicamente, se vc alterar a implementação do metodo (não os argumentos, nem os retornos), para quem usa esse metodo ainda vai continuar como se nada tivesse mudado.

Qual a vantagem de se usar uma linguagem OO se não utilizar o principio basico da OO a herança? quer queira quer não vc esta usando herança em todo o java (java.lang.Object).[/quote]

Acho que há confusão de conceitos. Um jeito eficiente de promover baixo acoplamento é criar variáveis cujo tipo seja uma interface, não uma classe. E aí, quando eu quiser mudar a implementação, basta mudar a instância da classe.

Mudar a implementação do método nem sempre é uma alternativa viável, uma delas é quando você não tem acesso ao código principal, outra é quando nem todo o sistema precisa de um novo código (mas só parte dela).

Voltando.

Às vezes, as pessoas dizem que herança é ruim, mas é uma supersimplificação. Uma explicação mais extensa é:

:arrow: não use herança quando, no mundo real, não existe uma relação de é-um entre os tipos. Isso já é suficiente para eliminar 95% das heranças feitas por aí, como AtividadeController herdar de BaseWeb ou Properties herdar de Hashtable. Porém, em alguns raros casos, a herança é legítima. Exemplo óbvio é o fato de todas as classes herdarem de Object, pois, no mundo real, qualquer instância é um objeto.

:arrow: Esse negócio de que herança é ruim existe apenas devido à implementação do modelo de objetos do Java. Não vai achar que isso seria válido para outras linguagens OO, mas cujo modelo é diferente, como Ruby ou Python. Em Java, herança é ruim pois, uma vez definido o supertipo, não é possível mudá-lo em tempo de execução. Outra é que a tipagem é estática, ou seja, se mudar o supertipo mas manter o contrato dos métodos, ainda assim não será possível referenciar as classes nas variáveis antigas.