4
respostas

É correto esta situação segundo a regra de SOLID

Bom dia senhores, estou com uma dúvida.

Tenho as classes:

class A {
    private int codigo;
    private String nome;
    ...
    public int getCodigo(){
        return codigo;
    }
    public String getNome(){
        return nome;
    }
}
class B {
    private int codigo;
    private A a;

    public int getCodigo(){
        return codigo;
    }
}

O que seria o melhor a se fazer para fornecer os dados de B? Criar um método de acesso ao dado como:

public A getA(){
    return a;
}

Ou passar os dados de B como se fossem dados de A, sem que se expor a B ao clientes da classe A.

public int getACodigo(){
    return a.getCodigo();
}

Segundo as melhores práticas qual seria melhor abordagem?

4 respostas

Bom dia Tiago, tudo bom?

Eu iria pela segunda abordagem.

public int getCodigo(){
    return a.getCodigo();
}

Dessa maneira você está escondendo o fato que o código de B depende do código de A.

Com isso, se você decidir mudar a lógica do seu sistema e fazer com que o código de B não dependa de A. Só precisaria mudar a classe B e os clientes dela continuariam funcionando normalmente.

Se fossemos pela primeira abordagem, o Método getCodigo de B depende da implementação de A. Assim, se você quiser mudar a lógica da Classe B e alterar o tipo de retorno todos os clientes vão quebrar e você terá que mudar seu código em muitas partes.

Bacana, obrigado.

Ricardo Bugan, independente de quantidade de propriedades que a classe "A" tenha, você sempre cria métodos em "B" dos métodos de acesso de "A", correto (delegando apenas)?

E caso a classe "A" tenha mais composições, faz sentido "A" ter novamente os métodos de acesso aos dados da que a compõem e "B" replicar isso tudo?

Estou com esta dúvida, pois a classe "A" pode ficar bem grande com tanto métodos que só delegam? É correto?

Caso não, como resolveriam isso?

Oi Tiago, tudo bom?

Na verdade não, eu não vou criar métodos em "B" que sirvam de acesso para todas as propriedades e métodos de "A".

Eu só vou implementar métodos em "B" que façam sentido para essa classe. Acontece que alguns desses métodos podem depender da implementação de "A".

Existe um padrão de projeto que é chamado de "Proxy" em que criamos uma classe que serve para controlar acesso de um segundo objeto e nesse caso é mais comum criarmos um método em B para cada método em A. Isso porque B faz algumas verificações antes de chamar os métodos de A.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software