Herança, Polimorfismo e Encapsulamento: C# te ajudando a colocar a teoria na prática com Modificadores de Acesso

Olá pessoal, venho aqui agora compartilhar uma dúvida que acho que muitas pessoas tem depois de saem da faculdade. Que é como colocar aquela teoria de Herança, Polimorfismo e Encapsulamento na prática. Se você pensa que é somente herdar e sobrescrever uma classe e “tá tranquilo”, você está um pouco errado. As vezes você está em algum cenário em que você não vai poder usar somente isto, ou que, ficaria mais “elegante” utilizar alguns modificadores de acesso. Sabe? aqueles “public, private, protected, abstract, internal, partial” que você já deve ter visto em algum lugar.

polimorfismo-capa

Bom então vamos lá conhecer estes Modificadores de Acesso pensando em Herança, Polimorfismo e Encapsulamento em C#!

Classes Abstract

Classes abstract não podem ser instanciadas, mas podem ser herdadas, ou seja, podem ter filhas. São muito usadas pra fazer classe base, com métodos que devem ou não serem implementados. Abaixo tem um exemplo.

Abstract - Implementação
Abstract – Implementação

No meu caso, eu criei uma classe abstrata com um método publico com implementação. Um cenário que isso poderia ser aplicado é que eu tenho uma classe base que tem umas funções padrões. Como uma classe abstrata “Mamífero”, com um método padrão “Alimentar” padrão, já que todos os mamíferos bebem leite. Mas se eu também tiver um método padrão “TerFilhote”, o método terá que ser sobrescrito para a classe “Ornitorrinco” que herda de “Mamífero”. Não sei se sabem, mas Ornitorrinco é o único mamífero que bota ovos.

Com isso estamos combinando Herança (herdando de mamíferos) e também polimorfismo (sobrescrevendo o método “TerFilhote”).

Abaixo está um teste demonstrando que eu não posso instancia-la, somente herdando que utilizo seus métodos.

Abstract - Testes
Abstract – Testes

Classes Internal

Classes Internal são classes que definem um limite de onde podem ser usadas. Elas só podem ser utilizadas no mesmo assembly onde ela é declarada. Ou seja, só no projeto em que ela está que ela pode ser usada, e isso pode ser dito para métodos Internal também.

Abaixo um exemplo.

Classe Internal 1 - Implementacao
Internal – Implementação de uma classe Internal e também uma classe publica com método Internal

Acima implementação de uma classe Internal com método publico, e uma classe publica com método Internal e outro publico.

Classe Internal 2 - Teste em outro assembly
Internal – Teste das classes em outro assembly

Neste caso estamos em outro assembly (outro projeto), fazendo referencia ao projeto onde estão as classes. Como podem ver, não posso instanciar a classe Internal. Já a publica eu consigo, mas não consigo acessar o método Internal, somente o método publico.

Classe Internal 3 - Teste no mesmo assembly
Internal – Testes das classes no mesmo assembly

Agora o mesmo teste anterior, só que no mesmo assembly onde as classes foram criadas. Como podem ver, sem erro nenhum.

A utilidade desse tipo de classe é muito comum para bibliotecas e frameworks. Imagine que você fez toda uma logica de acesso ao banco de dados em uma classe especifica de um projeto que é uma biblioteca (Class Library), e vai disponibilizar ela pro seu time utilizar. Para não correr riscos de utilizarem classes erradas, como classes de regras e calculo, você transforma elas em internal, e disponibiliza somente as que você quer que eles utilizem.

Com isso estamos utilizando de forma muito bacana e segura a teoria do Encapsulamento.

Classes Partial

Classes Partial, como o nome mesmo sugere, são “partes” de uma classe. Uma classe partial é uma classe que pode ser implementada em pedados, que em tempo de compilação irá se juntar e formar uma única classe.

Vamos ao exemplo pra você entender.

Partial 1 - implementacao
Partial – Classes com esse modificador, são pedaços de classe, mas que no final viram uma só classe

Acima como pode ver declaro duas classes com o mesmo nome “Impressora” e o visual studio me deixa fazer isso tranquilamente. Sabe por que? Porque são classes partial, com isso posso implementar partes dessa classe no meio do meu assembly.

Abaixo um teste dessas classes

Partial 2 - testes
Partial – Teste

Como podem ver eu declarei uma vez a classe impressora, e a própria IDE já me mostrou os métodos disponíveis, mesmo eles estando em lugares diferentes. Que são “ImprimirExcel” e “ImprimirWord”.

Os cenários para aplicar esse tipo de modificador pra mim são bem restritos. Já pensei que poderia ser pra trabalhar em paralelo, 2 desenvolvedores atuando na mesma classe. Mas também já temos exemplos prontos, os formulários windows forms por exemplo, temos uma classe partial para o design e outra para nós programarmos eventos e a lógica. No final, ao compilar, essa duas classes virarão somente uma.

Caso pensem em mais algum cenário com este tipo de modificador por favor compartilhe nos comentários.

Métodos Protected

Se não notou, aqui só vou falar sobre os MÉTODOS Protected. Por que não achei uma forma de implementar classes protected, os métodos pra mim foram mais úteis.

Os métodos Protected são aqueles que podem ser usados dentro da classe, mas não podem ser utilizados por instancias da classe. E ele pode ser invocado fora da classe, só se for de uma derivada/filha da classe.

Confuso? vamos no exemplo.

Protected 1 - Implementacao
Método Protected – declaração de um método protected

Acima criei uma classe publica com um método protected.

Protected 2 - Teste no mesmo assembly
Método Protected – Teste de instância. *Correção: Não é classe protected e sim classe publica com método protected

Como podem ver eu instanciando essa classe, eu não posso utilizar o método protected que eu criei

Protected 3 - Teste em outro assembly
Método Protected – Herdando a classe posso invocar o método

Acima podemos ver que herdando a classe podemos utilizar o método que é protected.

A aplicação disso pode ser justamente pensando em Herança. Por exemplo a classe “Mamífero”, que mentalmente nós criamos mais pra cima aqui no post, colocando o método de “Alimentar” como protected, nós estamos assegurando que somente os mamíferos irão invocar este método, assim combinando os modificadores de acesso abstract (não permitir instancias e sim heranças) e protected (permitir que somente derivadas/filhas invoquem os métodos).

Classes Sealed

Como o próprio nome diz, esse modificador deixa sua classe selada em questão de “ter filhas”. Com este modificador sua classe se torna estéril pode ser somente instanciada e não pode ser herdada por qualquer outra.

Vamos ao exemplo:

Sealed 1 - Implementacao
Classe Sealed – Declarando um classe sealed

Acima declaro uma classe Sealed.

Sealed 2 - testes
Classe Sealed – Teste

No teste da classe Sealed que criei é possível enxergar 2 cenários, o primeiro é criando uma instancia da classe e o segundo é tentando herdar a classe. Quando você compilar o código dará erro de compilação nesta parte do código por que essa classe não pode ser herdada.

Isso é bom pensando naquela nossa situação do banco de dados. Não tínhamos nossa biblioteca implementada utilizando Internal? Para que os nossos colegas que utilizarem nossa biblioteca não acessem essas classes? Então, podemos colocar agora, na classe que queremos disponibilizar (por ex. uma classe com nome de “DataBaseManager”) , o modificador de acesso Sealed, assim ela vai estar disponível para uso, só que não poderá ser herdada por nenhuma classe para que seu comportamento seja sobrescrito.

Assim aplicando mais segurança ao nosso Encapsulamento.

Classes/Métodos Public / Private

Bom, vocês devem conhecer bem estes modificadores não é? Por isso não vou ser muito longo na explicação deles. Basicamente “public” define aquela classe/método disponível pra qualquer um. E “private” é ao contrário, deixando disponível em um escopo somente de classe.

Conclusão

Bom pessoal, gostei muito de escrever este artigo, espero que tenha ajudado vocês a clarear mais a mente sobre o assunto e as possibilidades de uso destes modificadores. Caso queiram baixar os testes que fiz aqui neste link.

Caso tenham alguma sugestão ou dúvida o espaço de comentários é de vocês, fiquem a vontade!

Rock ON \o/

Kelvin

Anúncios

8 comentários sobre “Herança, Polimorfismo e Encapsulamento: C# te ajudando a colocar a teoria na prática com Modificadores de Acesso

  1. Geanderson S. Silva 21/02/2015 / 01:55

    Show esse artigo, já estudei muito sobre, mas a clareza e lingugem com que explicou ficou excelente.

    • Kelvin Rodrigues 31/01/2015 / 13:46

      Valeu demais Daniel !!
      Pode deixar que tentarei continuar e melhorar nesta linha 😀

  2. teamsoftware 28/01/2015 / 15:29

    Muito bom o artigo. Continue nessa linha, parabéns.

    Sugestão de novos posts relacionados a este assunto, uso de interfaces e simulação de heranças múltiplas bem como fortes contratos. Também uso de interfaces para acesso a outros assemblys por meio de reflection.

    • Kelvin Rodrigues 29/01/2015 / 11:36

      Opa, Valeu demais!

      Estou pensando em sim seguir nessa linha, é muito bacana POO desse nivel.

      Muito legal as suas sugestões, valeu! vou até pesquisar mais sobre isso, por que ainda não conheço muito também.

      Abs

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s