Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Implementando heranca, classe abstrata e interface. Compreensao sobre o uso da palavra virtual

Ola Guilherme, gostaria de sua opiniao sobre algumas questoes para solidificar meu entendimento sobre o que aprendemos ate aqui de heranca, classe abstrata, virtual, interface. Criei o seguinte cenario: No link contem o diagrama UML (https://drive.google.com/file/d/1URXcyAn-IcXj4n8fws4a88kjfr_-f_RN/view?usp=sharing) -Criei uma classe Funcionario abstrata porque nao quero instanciar objetos dessa classe. -Criei uma classe Gerente de Projeto que herda de Funcionario porque a mesma tem especificidades, se nao as tivesse usaria a classe pai nao mais como abstrata. -Uso como regra para heranca se a classe filha vai conter propriedades, e/ou metodos diferentes, ou implementacoes diferentes do mesmo metodo da classe pai. Correto a regra? Nao vejo sentido para heranca quando quero especificar uma classe que nada tem de diferente da classe pai. -Implementei uma interface bonificacao pois nem todos os tipos de funcionarios terao bonificacao. Seu eu criasse um metodo abstrato na classe pai nao satisfaria essa condicao pois obrigo as classes filhas implementarem o metodo. Nao usei virtual na classe pai pois tambem entendo que apesar de virtual nao obrigar as classes filhas implementarem, as classes filhas terao acesso a implementacao do metodo pela classe pai, o que tambem nao atende. Entao, meu entendimento sobre o uso do virtual eh que so faco uso do mesmo se todas as classes pai e filhas vao fazer uso do metodo, seja ele do metodo oriundo do pai, ou seja o override no filho. Em resumo, virtual nao te obriga a implemetar como o abstract mas te permite usar o que ta implementado caso voce nao de override na implementacao na heranca, o que tambem nao atendia meu cenario. Correto o uso e o entendimento, nesse caso, de interface? Entendo que poderia criar uma classe so com propriedades e metodos que alguns funcionarios teriam, como o caso da bonificacao, e esta classe herdaria de Funcionario, e a classe Gerente de Projeto ou qualquer outra nova classe que tenha bonificacao herdaria dessa nova classe, evitando repeticao de codigo. Correto? A interface aqui neste caso precisaria de fato ser implementada? Ou so se eu tivesse , por exemplo um prestador de servico, que nao esta no sistema de pagamento, aumento de salario etc mas recebe bonificacao?

Agradeco as confirmacoes, observacoes e dicas. Abraco

Classe Funcionario

namespace OOP.Employees
{
    abstract class Employee
    {
        public string FullName { get; set; }
        public double Salary { get; protected set; }
        public Department Department { get; set; }

        protected Employee(string fullName, double salary, Department department)
        {
            FullName = fullName;
            Salary = salary;
            Department = department;
        }

        public abstract void UpdateSalary();

    }
}

Classe Gerente de Projeto

namespace OOP.Employees
{
    class ProjectManager : Employee, IBenefits
    {
        public double SalaryUpdated { get; private set; }
        public double Bonification { get; private set; }

        public ProjectManager(string fullName, double salary) : base(fullName, salary, Department.TBD)
        {
        }

        public void GiveBonification()
        {
            Bonification = Salary;
            Salary += Salary;
        }

        public override void UpdateSalary()
        {
            SalaryUpdated = Salary * .1;
            Salary *= 1.1;
        }

    }
}

Enum para lista de departamento

namespace OOP
{
    public enum Department
    {
        HR,
        IT,
        SALES,
        PROCUREMENT,
        ENGINEERING,
        TBD
    }
}

Interface Bonificacao

namespace OOP.Employees
{
    interface IBenefits
    {
        void GiveBonification();
    }
}

Programa

            ProjectManager pm = new ProjectManager("Richard Zampieri", 5000);
            pm.Department = Department.IT;
            pm.UpdateSalary();
            pm.GiveBonification();

            Console.WriteLine("Employee name: {0}", pm.FullName);
            Console.WriteLine("Current salary: {0}", (pm.Salary - (pm.SalaryUpdated + pm.Bonification)));
            Console.WriteLine("Department: {0}", pm.Department);
            Console.WriteLine("Salary raise: {0}", pm.SalaryUpdated);
            Console.WriteLine("Employee bonus: {0}", pm.Bonification);
            Console.WriteLine("New salary: {0}", pm.Salary);
2 respostas
solução!

Sobre herança sem mudança de comportamento ou criação de novos membros: Sim, você está correto. Não é necessário usar herança aqui.

Sobre o uso de virtual, o que você quer dizer por "todas as classes pai e filhas vao fazer uso do metodo"? Se é um método público, é possível que outra classe faça uso. O virtual é bom quando você está escrevendo uma classe, vê um comportamento padrão, mas ainda há a possibilidade de comportamentos diferentes, por parte das classes derivadas.

Sobre a bonificação, faz sentido separar em uma interface se você não a usar esperando um funcionário. Sua interface IBenefits possui apenas o método GiveBonification. Mas, você vai usar somente este método? Benefícios e bonificação parece uma coisa inerente aos funcionário. Nesse caso, não é problema criar o método GiveBonification virtual retornando 0 na classe base.

Outra alternativa, seria implementar IBenefits já na classe base. Desta forma, todo funcionário terá este método e o prestador de serviço também.

O que você acha?

Classe Abstrata: Obrigo as derivadas a implementarem os metodos

  • Classe com metodo virtual: permito que classes filhas/derivadas tenham acessam ao metodo da classe pai ou implementem sua propria versao do metodo com override
  • Especializacao de classe, como o exemplo FuncionarioAutenticavel, permite que atribuamos determinado comportamento somente a algumas classes
  • Interface: Contrato. Obriga qualquer classe ou estrutra implementar todos os seus membros. Beleza, agora eh praticar em cenarios do mundo real e ir vendo quais me trazem mais beneficios em termos de clareza do codigo, manutencao e organizacao.

Excelente, esclareceu. Obrigado Guilherme.