Fundamentos b�sicos da Orienta��o a Objetos

Por que eu devo ler este artigo:Este artigo trata sobre os principais fundamentos da orientaç�o a objetos em C#, explicando os conceitos de abstraç�o, herança, polimorfismo al�m de falar sobre a implementaç�o de alguns destes fundamentos em C#, assim como palavras reservadas dele que incidem sobre estes conceitos.

Os t�picos abordados neste artigo poder�o ser �teis no dia a dia de todo desenvolvedor, pois abordar�:

Guia do artigo:

Programaç�o estruturada VS Programaç�o Orientada a Objetos
Tipos de Refer�ncia x Tipos de Valor
Class x Struct
Herança
Virtual x Override
Modificadores de Acesso
Modificador Abstract
Modificador Sealed
Modificador Partial

Fundamentos b�sicos de Orientaç�o a Objetos

Neste artigo veremos os principais conceitos e fundamentos da orientaç�o a objetos aplicados no C#. Al�m disso, veremos o uso das palavras chaves virtual, override, abstract, sealed, partial e dos modificadores de acesso public, protected, internal, protected internal e private.

Atualmente existem dois paradigmas principais de desenvolvimento de software na mente dos desenvolvedores e no mercado. Temos o paradigma estruturado, que antes dominava o mercado, e o paradigma da orientaç�o a objetos (O.O), que cada vez mais vai tomando conta do mercado.

Normalmente, profissionais mais antigos est�o habituados com o paradigma estruturado e os mais novos com o paradigma O.O, mas � claro que isso n�o � uma regra.

O fato � que a orientaç�o a objetos vem tendo sua adoç�o numa crescente no mercado, mas � fato tamb�m que na maioria das vezes ela � subutilizada. � muito comum vermos equipes de desenvolvimento que desconhecem alguns fundamentos b�sicos da orientaç�o a objetos, que s�o os pilares dela.

A ideia deste artigo � apresentar alguns dos conceitos mais b�sicos e fundamentais da orientaç�o a objetos, com exemplos pontuais e aplicados ao C#. Vamos aproveitar tamb�m para falar sobre algumas palavras reservadas do C# que est�o de certa forma relacionadas aos conceitos que vamos apresentar.

Para começar, vamos traçar um breve comparativo, sobre os paradigmas estruturados e orientado a objetos.

Programaç�o estruturada VS Programaç�o Orientada a Objetos

Antigamente, h� algumas d�cadas atr�s, o paradigma que predominava no desenvolvimento de software era o da programaç�o estruturada. Basicamente, a grosso modo, os softwares eram compostos por rotinas e sub-rotinas que chamavam umas �s outras, al�m de vari�veis que tinham escopo local (dentro de rotinas / sub-rotinas) ou global. Assim como todo paradigma, o paradigma estruturado tinha seus pr�s e contras e foi bastante eficiente no que se prop�s durante seus anos de dom�nio no mercado, al�m de ter sido bastante importante para a evoluç�o da engenharia de desenvolvimento de software.

Com o passar dos anos, surgiu o paradigma da orientaç�o a objetos, que tamb�m n�o � t�o novo como muitos pensam, mas que veio a ganhar mais força na �ltima d�cada.

A orientaç�o a objetos surgiu com o objetivo de tornar o desenvolvimento de software menos complexo e mais produtivo. A ideia era termos estruturas de dados, que possuem estado e comportamento e colaboram entre si. Dessa forma, deixar�amos de ter todas as rotinas e sub-rotinas �espalhadas� pelo sistema e passamos a atribuir elas a uma dessas estruturas de dados, de forma coesa, cada qual com sua responsabilidade. Al�m disso, encapsular�amos as vari�veis nestas mesmas estruturas, controlando o acesso �s mesmas e tornando p�blico apenas aquilo que for pertinente.

O paradigma da orientaç�o a objetos possui tr�s conceitos fundamentais:

Encapsulamento � Prev� o isolamento a determinados elementos do objeto (m�todos /atributos) de acordo com a necessidade de acesso a eles. Este conceito parte da premissa de que nem todo m�todo e atributo precisam estar vis�veis e acess�veis publicamente. Existem elementos que s�o pertinentes apenas ao pr�prio objeto, outros pertinentes aos objetos filhos e outros que s�o pertinentes todos os objetos associados. O encapsulamento se d� atrav�s dos modificadores de acesso, que veremos mais a frente.
Abstraç�o � � a capacidade de focar nos pontos mais importantes do dom�nio de aplicaç�o do sistema e abstrair os detalhes menos relevantes. Na modelagem de um sistema orientado a objetos, uma classe tende a ser a abstraç�o de entidades existentes no mundo real (dom�nio da aplicaç�o). Ex.: Cliente, Funcion�rio, Conta Banc�ria.
Polimorfismo � � a capacidade de um elemento ser capaz de assumir diferentes formas. Na orientaç�o a objetos, chamamos de polimorfismo a possibilidade que temos de mudar o comportamento de um mesmo m�todo de um objeto dentro da sua hierarquia.

Al�m disso, podemos citar os seguinte elementos com sendo os alguns dos principais da orientaç�o a objetos:

Classe � Uma classe � um tipo de dado que representa tudo aquilo que um objeto deste tipo poder� ter/fazer. Na classe determinamos o que ser� armazenado em seu estado e quais comportamentos ele ter�, ela funciona como uma estrutura de refer�ncia para a criaç�o de objetos. Uma classe pode ter v�rios objetos.
Objeto � Um objeto � uma inst�ncia de uma classe. � a estrutura completa, criada em mem�ria, que representar� a classe com tudo o que foi definido nela, inclusive com os valores armazenados nos seus respectivos atributos.
Atributos � Os atributos representam o estado de um objeto. � neles que armazenaremos as informaç�es de nossos objetos. Ex.: Nome, Idade, Endereço etc.
M�todos � Representam os comportamentos (operaç�es) de nossos objetos, s�o as operaç�es que ele pode executar. Ex.: ValidarCPF, AprovarCredito, LiberarPagamento etc.

Figura 1. Representaç�o Gr�fica de classe com muitos objetos.

Na Figura 1, podemos ver que uma classe pode ser instanciada diversas vezes, dando origem a diversos objetos diferentes.

Tipos de Refer�ncia x Tipos de Valor

Em C# temos duas classificaç�es de tipos de dados. Que s�o os tipos de refer�ncia (References Types) e os tipos de valor (Value Types). A diferença chave entre os dois tipos � a na passagem de valores dos mesmos. No caso dos reference types, os valores dos objetos n�o s�o copiados, mas apenas sua refer�ncia, enquanto nos value types os valores s�o copiados de um objeto para o outro.

Todos os objetos que s�o do tipo de uma classe ou interface s�o reference types. Tipos enumerados e tipos primitivos s�o value types.

Ao atribuirmos uma refer�ncia de value type a outra, estamos literalmente copiando o seu valor, replicando-o para o novo elemento. Ao atribuirmos uma refer�ncia de um reference type para outro, n�o h� c�pia de valores, mas apenas de suas refer�ncias.

Listagem 1. Exemplo de Value Types

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.Modificadores;
  using ExemplosFundamentos.AbstractExemplo;
  using ExemplosFundamentos.PartialClass;
  
  namespace ExemplosFundamentos
  {
      class Program
      {
          static void Main(string[] args)
          {
              double valorA = 10;
              double valorB = 20;
              Console.WriteLine("valorA : " + valorA);
              Console.WriteLine("valorB : " + valorB);
              Console.WriteLine("Copiando valor de A para B...");
              valorB = valorA;
              Console.WriteLine("valorA : " + valorA);
              Console.WriteLine("valorB : " + valorB);
              Console.WriteLine("Alterando valor de A para 50...");
              valorA = 50;
              Console.WriteLine("valorA : " + valorA);
              Console.WriteLine("valorB : " + valorB);
              Console.ReadLine();
          }
      }
  }

Observe no exemplo da Listagem 1, primeiro declaramos duas vari�veis valorA e valor B, nas linhas 15 e 16 respectivamente. Com esta declaraç�o, imagine que temos dois espaços em mem�ria, um para a vari�vel valorA com o valor 10 e outro para a vari�vel valorB com o valor 20. Na linha 20 atribu�mos valorA ao valorB. Neste momento, o sistema copiou o valor de B para A, ent�o agora temos ainda dois espaços em mem�ria, um com o valorA de 20 e outro com o valorB tamb�m com 20. Na linha 24 alteramos o valorA mesmo para 50, passando a ter no primeiro espaço em mem�ria o valor de 50 e no segundo o valor de 20. Observe que ao atribuirmos o valorA ao valorB na linha 20, copiamos todo conte�do de uma posiç�o de mem�ria para outra. Na Figura 2, temos uma ilustraç�o do que ocorre ap�s a atribuiç�o.

Figura 2. Ilustraç�o - Atribuiç�o de Value Types.

Figura 3. Resultado da Listagem 1

Observando a Figura 3, podemos ver que o resultado da execuç�o de nosso c�digo. Observe que os valores de A e B se mantiveram independentes, mesmo ap�s atribuiç�o de um ao outro, pois o valor foi simplesmente copiado.

No caso dos reference types, ocorre algo diferente. Vejamos a Listagem 2.

Listagem 2. Exemplo de Reference Types

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.Modificadores;
  using ExemplosFundamentos.AbstractExemplo;
  using ExemplosFundamentos.PartialClass;
  using ExemplosFundamentos.SealedClass;
  
  namespace ExemplosFundamentos
  {
      class Program
      {
          static void Main(string[] args)
          {
              Produto produtoA = new Produto();
              produtoA.Descricao = "Computador Desktop";
              Produto produtoB = new Produto();
              produtoB.Descricao = "Notebook";
              Console.WriteLine("Produto A: " + produtoA.Descricao);
              Console.WriteLine("Produto B: " + produtoB.Descricao);
              Console.WriteLine("......");
              Console.WriteLine("Atribuindo produtoB ao produtoA");
              produtoA = produtoB;
              Console.WriteLine("Produto A: " + produtoA.Descricao);
              Console.WriteLine("Produto B: " + produtoB.Descricao);
              Console.WriteLine("......");
              Console.WriteLine("Alterando a descriç�o de produtoA para Scanner");
              produtoA.Descricao = "Scanner de Mesa";
              Console.WriteLine("Produto A: " + produtoA.Descricao);
              Console.WriteLine("Produto B: " + produtoB.Descricao);
              Console.ReadLine();
          }
      }
  }

Na Listagem 2 temos um exemplo semelhante, por�m ao inv�s de usar vari�veis do tipo Double, estamos usando objetos do tipo Produto. Nas linhas 16 e 18 criamos dois objetos do tipo Produto. Neste momento, temos duas vari�veis de refer�ncia apontando para dois espaços de mem�ria diferentes.

Na linha 24, atribu�mos produtoB ao produtoA. � neste ponto que entra a principal diferença entre value types e reference types. No caso de value types vimos que o valor foi copiado de uma vari�vel para outra. Neste caso, apenas a refer�ncia de produtoB � copiada para produtoA. Com isso, passamos a ter duas vari�veis, produtoA e produtoB, apontando para o mesmo espaço em mem�ria. Isso significa que a partir deste momento, qualquer alteraç�o que fizermos tanto em produtoA quanto em produtoB estar�o refletindo no mesmo espaço em mem�ria, isso pode ser mais bem observado na ilustraç�o da Figura 4.

Figura 4. Ilustraç�o - Atribuiç�o de Reference Types.

Figura 5. Resultado da Listagem 2

Observando a Figura 5, podemos observar que a partir do momento que atribu�mos produtoB ao produtoA, ambos passam a apontar para o mesmo espaço em mem�ria. Observe que ao alterarmos a descriç�o do produtoA para Scanner, o valor de produtoB tamb�m parece ter mudado. Na verdade, o que acontece � que produtoB est� apontando para o mesmo lugar de produtoA em mem�ria.

Mas e o que aconteceu com a inst�ncia criada na linha 16? Ela se perdeu e n�o conseguimos mais acessar a mesma, ficando a cargo do Garbage Collector a liberaç�o dela da mem�ria.

Nota do DevMan

Garbage Collector (GC) � o gerenciador de objetos em mem�ria do .NET respons�vel por liberar da mem�ria as inst�ncias n�o utilizadas pela aplicaç�o. Quando o GC identifica um objeto de sua aplicaç�o que n�o possui nenhuma refer�ncia, ele o destr�i liberando espaço em mem�ria.

Class x Struct

Quando declaramos uma classe, estamos criando um �modelo� de objetos. Estamos dizendo que todos os objetos daquele tipo ter�o determinados m�todos e atributos. Ao criarmos um novo objeto (com o operador new), estamos criando uma nova inst�ncia desta classe e retornando a refer�ncia para a esta inst�ncia.

Listagem 3. Exemplo de classe em C#

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
   
  namespace DevMedia.EasyNet
  {
      public class Cliente
      {
          public string Nome { get; set; }
   
          public int Idade { get; set; }
   
          public DateTime DataCadastro { get; set; }
      }
  }

Listagem 4. Exemplo de criaç�o de um objeto em C#

 
  Cliente cliente = new Cliente();
  cliente.Nome = "Ricardo Coelho";
  cliente.Idade = 25;
  cliente.DataCadastro = DateTime.Parse("09/02/2005");

Na Listagem 3 temos um exemplo de classe com os atributos referentes � cliente, enquanto na Listagem 4 temos a criaç�o de um objeto deste tipo (classe cliente). Vale ressaltar que toda classe � um reference type.

Compreendido este conceito, outro conceito que temos � o de struct. Um struct em .NET � uma estrutura de dados usada para agrupar dados que possuem algum tipo de relaç�o.

Um struct, apesar de ter a sintaxe parecida com a de uma classe, � um value type. Essa � a diferença fundamental entre eles. Um struct tamb�m suporta construtores (parametrizados), m�todos e properties, mas � preciso tomar cuidado, pois a ideia do struct � armazenar estruturas de dados pequenas, se voc� tem uma estrutura grande, ou com muitos m�todos, regras, � melhor avaliar o uso de uma classe. Nas Listagens 5 e 6 temos um exemplo de declaraç�o e uso de um struct.

Listagem 5. Exemplo de declaraç�o de um struct

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.StructExample
  {
      public struct PontoGeometrico
      {
          public string Latitude { get; set; }
          
          public string Longitude { get; set; }
      }
  }

Listagem 6. Exemplo de uso de um struct

 using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.StructExample;
   
  namespace ExemplosFundamentos
  {
      class Program
      {
          static void Main(string[] args)
          {
              PontoGeometrico ponto = new PontoGeometrico();
              ponto.Latitude = "-40.0.0";
              ponto.Longitude = "-20.0.0";
              Console.WriteLine("Latitude:" + ponto.Latitude);
              Console.WriteLine("Longitude:" + ponto.Longitude);
              Console.ReadLine();
          }
      }
  }

Herança

Em orientaç�o a objetos, herança � quando uma classe (filha) herda todas as caracter�sticas (atributos e m�todos) de outra classe (pai). A herança est� diretamente relacionada ao polimorfismo, pois atrav�s da herança podemos sobrescrever e estender funcionalidades do sistema.

Quando uma classe filha herda de uma classe pai, estamos dizendo que ela possui todas as caracter�sticas dela. A classe pai � considerada a classe gen�rica enquanto que suas classes filhas s�o consideras as classes especializadas.

A herança � uma faca de dois gumes, pois ao mesmo tempo em que pode ajudar trazendo mais reuso de c�digo, pode tamb�m atrapalhar gerando muito acoplamento entre seus objetos, visto que qualquer alteraç�o na classe pai ser� refletida diretamente em todas as classes filhas.

Uma classe pai pode ser herdada por diversas classes filhas, n�o existe limite para este caso. Por outro lado, uma classe filha s� pode ter uma classe pai, ou seja, o .NET n�o suporte herança m�ltipla de classes.

Listagem 7. Classe Pessoa � Classe Pai

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.Heranca
  {
      public class Pessoa
      {
          public string Nome { get; set; }
  
          public String Endereco { get; set; }
  
          public String Pais { get; set; }
      }
  }

Na Listagem 7 definimos nossa classe pai, Pessoa, que servir� de base para as outras. Observe que definimos apenas os itens que s�o comuns a todas as pessoas de nosso sistema, sendo os atributos Nome, Endereco e Pais. Sempre que criarmos uma hierarquia de classes em nossos sistemas, temos que tomar cuidado em colocar na classe pai apenas aquilo que realmente for comum a todos os filhos.

Listagem 8. Classe PessoaFisica

using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
   
  namespace ExemplosFundamentos.Heranca
  {
      public class PessoaFisica:Pessoa
      {
          public string CPF { get; set;}
   
          public string RG { get; set;}
      }
  }

Listagem 9. Classe PessoaJuridica

 using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
   
  namespace ExemplosFundamentos.Heranca
  {
      public class PessoaJuridica:Pessoa
      {
          public string CNPJ { get; set; }
   
          public string InscricaoEstadual { get; set; }
      }
  }

Nas Listagens 8 e 9 temos nossas classes filhas(especialistas), PessoaFisica e PessoaJuridica, onde temos a definiç�o dos atributos referentes � documentaç�o de cada uma delas. Observe que declaramos apenas aquilo que � exclusivo e pertinente a cada uma delas, por�m ambas possuem Nome, Endereco e Pais, pois herdam de Pessoa.

Nos exemplos acima, colocamos apenas um n�vel de hierarquia, por�m n�o h� limites impostos pelo framework para isso, poder�amos, por exemplo, criar outras classes, FornecedorNacional e FornecedorInternacional herdando de PessoaJuridica. Vale ressaltar o bom senso e a an�lise de cada caso, para evitarmos criar estruturas desnecessariamente complexas e acopladas em nossos sistemas.

Outro ponto interessante para citar a respeito de herança � sobre as regras de casting da mesma. Utilizando herança, � poss�vel atribuirmos uma inst�ncia de um objeto filho � uma vari�vel declarada do tipo de um objeto pai, como podemos ver na Listagem 10.

Listagem 10. Cast impl�cito - Herança


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.Heranca;
  
  namespace ExemplosFundamentos
  {
      class Program
      {
          static void Main(string[] args)
          {
              Pessoa pessoa = new Pessoa();
              Pessoa pessoaA = new PessoaFisica();
              Pessoa pessoaB = new PessoaJuridica();            
             (pessoaA as PessoaFisica).CPF = "9999999";
             Console.WriteLine((pessoaA as PessoaFisica).CPF);
             Console.ReadLine();
          }
      }
  }

Observe na Listagem 10, nas linhas 13, 14 e 15, que temos tr�s vari�veis declaradas e cada uma recebe uma inst�ncia de um tipo diferente. Isso � poss�vel, pois todos as inst�ncias usadas s�o da hierarquia de Pessoa (usada na declaraç�o da vari�vel). Por outro lado, no caso de pessoaA por exemplo, n�o conseguiremos acessar as propriedades espec�ficas de PessoaF�sica pois a vari�vel � do tipo Pessoa.

Para acessarmos as caracter�sticas de PessoaFisica na vari�vel pessoaA, ter�amos que fazer um cast expl�cito com o operador as, como mostrado nas linhas 16, 17. Vale ressaltar que o cast expl�cito s� ser� validado em tempo de execuç�o, podendo gerar um erro em tempo de execuç�o caso seja realizado um cast para um tipo diferente do tipo da inst�ncia. Por exemplo, se fiz�ssemos (pessoaA as PessoaJuridica).CNPJ = "5555555", obter�amos um erro em tempo de execuç�o.

Nota do DevMan

Type casting � como chamamos a convers�o de um determinado tipo para outro. Vale ressaltar que s� � poss�vel realizar o typecasting de elementos compat�veis com a inst�ncia da declaraç�o.

Virtual x Override

Agora que j� vimos os conceitos fundamentais da orientaç�o a objetos, o que � uma classe, um objeto e como funciona a herança, podemos falar sobre as palavras reservadas virtual e override.

Como vimos, podemos criar estruturas hier�rquicas nas classes, reaproveitando comportamento e estado das classes superiores, por�m, algumas vezes � preciso sobrescrever determinados comportamentos da classe pai nas classes filhas, aplicando assim o conceito de polimorfismo.

Em orientaç�o a objetos, dizemos que um m�todo � sobrescrito quando a implementaç�o dele prevalece com relaç�o � implementaç�o de uma classe pai.

As palavras reservadas virtual e override se aplicam exatamente a isso. Devemos usar a palavra reservada virtual para indicar que um m�todo pode ser sobrescrito, ou seja, na classe pai. E a palavra reservada override para indicar que o m�todo est� sobrescrevendo o m�todo da classe pai.

Vamos imaginar o seguinte cen�rio para nosso exemplo. Temos uma classe conta banc�ria, que possui os atributos de uma conta normal, agencia, numero da conta e d�gito. A ideia � que esta classe represente uma conta comum. Al�m disso, esta classe tem um m�todo GetTarifaManutencao que nos dir� qual o valor da tarifa mensal desta conta, conforme podemos ver na Listagem 11.

Listagem 11. Classe ContaBancaria


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.VirtualOverride
  {
      public class ContaBancaria
      {
          public int Agencia { get; set; }
  
          public int Conta { get; set; }
  
          public int Digito { get; set; }
  
          public double GetTarifaManutencao() {
              return 30;
          }
      }
  }

Al�m da ContaBancaria, teremos outras duas classes, ContaEspecial e ContaUniversitaria. A ideia � que estas tenham tarifas de manutenç�o diferenciadas da conta comum. Estas classes ir�o herdar de ContaBancaria e tamb�m ter�o o m�todo GetTarifaManutencao(), por�m por enquanto n�o vamos definir os mesmos como virtual/override, como podemos ver na Listagem 12 e 13.

Listagem 12. Classe ContaEspecial


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.VirtualOverride
  {
      public class ContaEspecial:ContaBancaria
      {
          public double GetTarifaManutencao()
          {
              return 20;
          }
      }
  }

Listagem 13. Classe ContaUniversitaria


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.VirtualOverride
  {
      public class ContaUniversitaria:ContaBancaria
      {
          public double GetTarifaManutencao()
          {
              return 10;
          }
      }
  }

Nas Listagens 12 e 13, temos as classes mais especializadas com as tarifas espec�ficas de manutenç�o. Observe que n�o sobrescrevemos os m�todos, apenas declaramos com o mesmo nome da classe pai. Vamos agora consumir estes objetos para ver o comportamento deles. Na Listagem 14 temos o c�digo para consumir nossos objetos. Observe que declaramos tr�s objetos ContaBancaria, sendo contaBancariaA, contaBancariaB e contaBancariaC. Por�m, temos uma inst�ncia de ContaBancaria, uma inst�ncia de ContaUniversitaria e uma inst�ncia de ContaEspecial.

Listagem 14. Classe ContaUniversitaria

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.VirtualOverride;
  
  namespace ExemplosFundamentos
  {
      class Program
      {
          static void Main(string[] args)
          {
              ContaBancaria contaBancariaA = new ContaBancaria();
              Console.WriteLine("contaBancariaA: " + contaBancariaA.GetTarifaManutencao());
              Console.WriteLine("...............");
              ContaBancaria contaBancariaB = new ContaUniversitaria();
              Console.WriteLine("contaBancariaB: " + contaBancariaB.GetTarifaManutencao());
              Console.WriteLine("...............");
              ContaBancaria contaBancariaC = new ContaEspecial();
              Console.WriteLine("contaBancariaC: " + contaBancariaC.GetTarifaManutencao());
              Console.WriteLine("...............");
              Console.ReadLine();          
          }
      }
  }

Figura 6. Resultado da execuç�o da Listagem 11 sem Virtual-Override.

Observando a Figura 6 podemos ver que apesar de termos criado os objetos de ContaUniversitaria e ContaEspecial, o m�todo que foi executado foi o da ContaBancaria, nos tr�s casos. Isso ocorreu porque n�s n�o criamos uma cadeia polim�rfica para este m�todo na nossa hierarquia de objetos ContaBancaria. Para criar esta cadeia, precisamos declarar o m�todo GetTarifaManutencao como virtual na classe ContaBancaria e declar�-lo como override nas classes filhas. Realizando estas alteraç�es, c�digo ficaria assim:


  ContaBancaria
          public virtual double GetTarifaManutencao() {
              return 30;
          }
   
  ContaUniversitaria
  public override double GetTarifaManutencao(){
              return 10;
          }
   
  ContaEspecial
  public override double GetTarifaManutencao()
          {
              return 30;
          }

Com estas definiç�es criamos nossa cadeia polim�rfica. Agora se executarmos novamente o c�digo da Listagem 14 teremos o resultado mostrado na Figura 7.

Figura 7. Resultado da execuç�o da Listagem 14 com Virtual-Override

Observando a Figura 7 percebemos que agora foi executada a implementaç�o de cada classe filha devido ao override. Com este exemplo, fica mais f�cil de compreender que, caso o m�todo seja sobrescrito em uma classe filha (assinado com a palavra reservada override), ele sempre prevalecer� com relaç�o ao m�todo de sua classe pai.

Modificadores de Acesso

Os modificadores de acesso (Access modifiers) s�o palavras reservadas do C# para determinar o n�vel de acesso que um determinado membro de um tipo ter�. Os modificadores de acesso s�o fundamentais para garantir o encapsulamento da orientaç�o a objetos. Os modificadores de acesso s�o aplicados aos elementos das classes e structs, em seus respectivos m�todos e atributos. O C# possui os seguintes modificadores de acesso:

Public � Este � o n�vel mais baixo de restriç�o. Ele indica que o elemento n�o ter� restriç�o de acessos, ou seja, qualquer classe/struct que o conheça poder� acess�-lo.
Protected � Este n�vel indica que o elemento s� poder� ser acessado de dentro da pr�pria classe/struct ou a partir de uma classe descendente.
Internal - Este n�vel de acesso indica que o elemento s� poder� ser acessado de dentro do assembly em que foi declarado.
Protected Internal �Este n�vel indica que o elemento s� poder� ser acessado por classes do mesmo assembly, e s� poder� ser acessado por classes de assemblies diferentes quando estas forem descendentes da classe onde fora declarado o elemento.
Private � Indica que o elemento s� poder� ser acessado de dentro da pr�pria class/struct em que for declarado.

Um assembly � uma unidade b�sica gerada pela compilaç�o de aplicaç�es no .NET. Servem para facilmente distribuir m�dulos e execut�veis que podem ser versionados no GAC. O GAC por sua vez serve para terminar com o problema existente de m�ltiplas vers�es da mesma DLL rodando no S.O. Para saber mais temos um artigo aqui na plataforma.

Listagem 15. Exemplo de Modificadores de acesso em C#


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.Modificadores
  {
      public class Pessoa
      {
          public string Nome { get; set; }
  
          protected int Idade { get; set; }
  
          private double Rendimento { get; set; }
  
          protected internal string Endereco { get; set; }
  
          internal string Estado { get; set; }
      }
  }

Na Listagem 15, temos a aplicaç�o de todos os modificadores citados acima. Com esta declaraç�o ter�amos o seguinte cen�rio:

Listagem 16. Classe sendo consumida no pr�prio assembly


 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;
 using ExemplosFundamentos.Modificadores;
 
 namespace ExemplosFundamentos
 {
     class Program
     {
         static void Main(string[] args)
         {
             Pessoa pessoa = new Pessoa();
             pessoa.Nome = "Ricardo";
             pessoa.Estado = "RJ";
             pessoa.Endereco = "Rua XPTO";
         }
     }
 }

Na Listagem 16 temos a nossa primeira simulaç�o de uso do nosso objeto pessoa. Imaginemos uma classe consumidora (no mesmo assembly de Pessoa), criando um objeto do tipo pessoa. Neste caso, s� conseguimos acessar os atributos Nome, Estado e Endereco, pois os mesmos s�o Public e Internal.

Ao tentarmos criar um objeto Pessoa (linhas 13 a 16) e popular o mesmo em um outro assembly, obteremos um erro de compilaç�o, indicando que n�o podemos acessar as propriedades Estado e Endereco, devido ao fato das mesmas terem o modificador Internal.

Por outro lado, na Listagem 17 temos a declaraç�o de uma classe PessoaFisica, que herda de pessoa. Vamos imaginar que esta classe est� em um assembly diferente do de Pessoa.

Listagem 17. Classe PessoaFisica herdando de Pessoa, em outro assembly


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.Modificadores;
  
  namespace ExemplosFundamentos.V2
  {
      public class PessoaFisica:Pessoa
      {
          public PessoaFisica(){
              base.Nome = "Ricardo";
              base.Idade = 25;
              base.Endereco = "Rua XPTO";
              base.Estado = "RJ";
          }
      }
  }

No caso da Listagem 17, conseguiremos acessar Endereco, pois ele � Internal Protected, o que significa que este s� poder� ser acessado em outros assemblies quando estiver classes descendentes.

Assim como no caso das properties, que exemplificamos acima, os modificadores de acesso tamb�m podem ser aplicados a m�todos da classe/struct, seguindo as mesmas regras das listagens explicadas acima. Inclusive, eles podem ser aplicados a m�todos construtores. H� casos em que queremos obrigar que a classe consumidora, ao instanciar um novo objeto passe determinados par�metros, ent�o colocamos o construtor default como private para que ele n�o possa ser acessado, como mostrado na Listagem 18.

Listagem 18. Construtor padr�o privado


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.Modificadores;
  
  namespace ExemplosFundamentos.V2
  {
        public class PessoaFisica:Pessoa
        {
             private PessoaFisica(){
        
             }
  
             private PessoaFisica(string nome, int idade, string endereco, string estado){
                  this.Nome = nome;
                  this.Idade = idade;
                  this.Endereco = endereco;
                  this.Estado = estado;  
              }        
         }
  }

Na Listagem 18 podemos ver que estamos obrigando que o objeto PessoaFisica seja criado passando-se o nome, idade, endereço e estado como par�metros.

Outro caso muito comum de uso do construtor privado � na implementaç�o do design pattern Singleton.

Nota do DevMan

Singleton � um design pattern que prev� a criaç�o de apenas uma inst�ncia de um determinado objeto. Para isso, os construtores s�o definidos como private e � criado um atributo est�tico de refer� ncia da pr�pria classe, al�m de um m�todo, normalmente chamado GetInstance. Na implementaç�o do GetInstance, � verificado se o objeto da vari�vel est�tica existe ou n�o, caso n�o exista, ele � instanciado, caso exista ele � simplesmente retornado. Podemos observar um exemplo de implementaç�o do Singleton na Listagem 19.

Listagem 19. Exemplo de construtor privado com Singleton


 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;
 
 namespace ExemplosFundamentos.V2
 {
     public class Conexao
     {
         private static Conexao _conexao { get; set; }
 
         public string DataBasePath { get; set; }
 
         public string UserName { get; set; }
 
         public string PassWord { get; set; }
 
         private Conexao()
         {
 
         }
 
         public static Conexao GetInstance(){
             if(_conexao == null)
                 _conexao = new Conexao();
 
             return _conexao;
         }
     }
 }

Modificador Abstract

Este modificador pode ser aplicado tanto a classes quanto a m�todos. Quando utilizamos ele, estamos dizendo ao .NET que o elemento em quest�o � um elemento abstrato e que n�o ter� implementaç�o, ficando a mesma a cargo das classes filhas. Quando este modificador � usado em uma classe, estamos dizendo que a mesma n�o pode ser instanciada.

Al�m disso, um m�todo s� poder� ser definido como abstract se a classe em que ele estiver contido for uma abstract class, como podemos ver na Listagem 20.

Listagem 20. Exemplo de abstract class


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
   
  namespace ExemplosFundamentos.AbstractExemplo
  {
      public abstract class ClasseBase
      {
          public abstract string GerarIdentificador();
      }
  }

Se tentarmos instanciar um objeto do tipo ClasseBase (como no c�digo abaixo), obteremos o seguinte erro:


Cannot create an instance of the abstract class or interface 'ExemplosFundamentos.AbstractExemplo.ClasseBase'

Outra caracter�stica importante de ressaltar � que os m�todos definidos como abstract, precisam obrigatoriamente ser implementados nas classes descendentes, fazendo com que tenhamos um comportamento semelhante ao da interface. Al�m disso, como existe esta obrigatoriedade, tais m�todos s�o definidos internamente como virtuais pelo .NET. Na Listagem 21 vemos um exemplo de classe descendente de uma classe abstrata. Observe que se n�o implementarmos o m�todo GerarIdentificador na classe cliente, obteremos uma mensagem de erro de compilaç�o.

Listagem 21. Exemplo de abstract class

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.AbstractExemplo
  {
      public class Cliente : ClasseBase
      {
          public string Nome { get; set; }
  
          public string CPF { get; set; }
  
  
          public override string GerarIdentificador()
          {
              return CPF;
          }
      }
  }

A seguir segue o erro apresentado caso o GerarIdentificador n�o seja implementado na classe descendente.

'ExemplosFundamentos.AbstractExemplo.Cliente' does not implement inherited abstract member 'ExemplosFundamentos.AbstractExemplo.ClasseBase.GerarIdentificador()'

M�todos abstratos s�o muito comuns quando estamos implementando o design pattern TemplateMethod.

Template Method � um design pattern que prev� a quebra de pedaços de um determinado algoritmo em partes abstratas, de forma que a classe base n�o necessite conhecer sua total implementaç�o, mas apenas o roteiro do mesmo. Na implementaç�o do template method, a classe base pode ter a implementaç�o de algumas partes do algoritmo e delegar a responsabilidade de implementaç�o de outras partes para classes filhas.

Podemos exemplificar o uso do template method na Listagem 22, imagine um cen�rio hipot�tico onde ter�amos a classe venda, que ter�amos que aplicar descontos diferenciados para cada tipo de venda. Por exemplo, venda a vista teria 10 % de desconto e venda a prazo teria 5% de desconto. No nosso exemplo, ter�amos uma classe pai, chamada venda, e duas classes filhas, chamadas VendaVista, VendaPrazo respectivamente.

Listagem 22. Exemplo de Template Method - Classe pai

 
  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using ExemplosFundamentos.SealedClass;
  
  namespace ExemplosFundamentos.AbstractExemplo
  {
      public abstract class Venda
      {
         public DateTime DataVenda { get; set; }
  
          public String Vendedor { get; set; }
  
          public IList<Produto> Produtos { get; set; }
  
          public double  CalcularValorLiquidoVenda() {
              double desconto = CalcularDescontoCliente();
  
              double valorTotalProdutos = CalcularTotalProdutos();
  
              return valorTotalProdutos - desconto;
          }
  
          public abstract double CalcularDescontoCliente();
  
          public double CalcularTotalProdutos(){
              double total = 0;
              
              foreach(Produto produto in Produtos){
                  total += produto.Valor;
              }
  
              return total;
          }
      }
  }

Observe na Listagem 22, que a classe venda conhece o algoritmo para calcular o valor liquido de uma venda, mas desconhece o algoritmo para calcular o desconto do tipo de venda. Na linha 17, perceba que fazemos uso do m�todo CalcularDescontoCliente, mesmo este sendo abstract (veja linha 23).

Na Listagem 23 temos a implementaç�o deste m�todo nas classes filhas.

Listagem 23. Exemplo de Template Method - Classes filhas


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.AbstractExemplo
  {
        public class VendaVista:Venda
        {
               public override double CalcularDescontoCliente()
               {
                      return 5;
               }
        }
  
        public class VendaPrazo : Venda
        {
               public override double CalcularDescontoCliente()
               {
                      return 10;
               }
         }
  }

Modificador Sealed

Este modificador � bem simples. Ele indica que a classe em quest�o n�o pode ser herdada. Caso voc� tente criar uma classe filha de um uma Sealed class, obter� um erro em tempo de compilaç�o.

Listagem 24. Exemplo de sealed class


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.SealedClass
  {
      public sealed class Produto
      {
          public string Descricao { get; set; }
  
          public double Valor { get; set; }
      }
  }

Na Listagem 24 temos um exemplo de uso da palavra reservada sealed. Neste caso, se tent�ssemos criar uma classe herdando de Produto, obter�amos o seguinte erro de compilaç�o:

'ExemplosFundamentos.SealedClass.ProdutoIndustrializado': cannot derive from sealed type 'ExemplosFundamentos.SealedClass.Produto'

Outro ponto importante a ressaltar, � que uma classe marcada como Abstract n�o pode ser sealed, visto que a classe abstract necessita de classes descendentes para implementar seus m�todos abstratos, enquanto a classe sealed n�o permite isso.

Modificador Partial

O C# nos permite separar um mesmo tipo, seja uma classe, uma interface ou um struct, em diversos arquivos diferentes atrav�s do modificador partial. Com ele, podemos criar uma classe Cliente, em um arquivo, inserir algumas funcionalidades, e criar o arquivo Cliente2 com outros m�todos.

Listagem 25. Exemplo de Partial Class


  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  
  namespace ExemplosFundamentos.PartialClass
  {
      public partial class Fornecedor
      {
          public Boolean IsCNPJValido() { 
              //Validacao de CNPJ
              return true;
          }
      }
  
      public partial class Fornecedor
      {
          public Boolean IsFornecedorEstrageiro()
          {
              //Validacao de Fornecedor Estrangeiro
              return true;
          }
      }
  
  }

Na Listagem 25 n�s temos um exemplo de definiç�o de partial class. Nela temos a definiç�o da classe Fornecedor duas vezes. Ao compilar este c�digo, o C# ir� entender que temos apenas uma classe Fornecedor, e tanto o m�todo IsCNPJValido quanto o m�todo IsFornecedorEstrageiro estar�o presentes na mesma pois no final das contas, a classe Fornecedor vai ser fruto da combinaç�o de todas as definiç�es de partial class dela. O recurso de partial class � usado pelo pr�prio .NET na criaç�o de Windows Forms, para separar o c�digo referente aos controles inseridos na tela(arquivo .designer.cs, gerado pelo Visual Studio) do c�digo digitado pelo programador(arquivo .cs).

Existem algumas ponderaç�es importantes com relaç�o ao modificador partial, sendo elas:

Se qualquer uma das partes for definida como abstract, Sealed ou herdar de uma classe pai, toda a classe ter� tais caracter�sticas.
Ele s� pode ser aplicado �s classes, interfaces e structs.

Conclus�o

Neste artigo tivemos uma introduç�o a alguns conceitos de orientaç�o a objetos, assim como algumas palavras reservadas do C# que tem alguma relaç�o com os conceitos abordados de orientaç�o a objetos.

A orientaç�o a objetos � um paradigma n�o t�o simples de ser explicado e compreendido. � preciso tempo e dedicaç�o para que se consiga absorver este paradigma e pensar orientado a objetos. Neste artigo apresentamos alguns conceitos b�sicos, iniciais, por�m fundamentais para novos estudos e avanços no paradigma.

Ap�s compreender os conceitos e fundamentos da orientaç�o a objetos, voc� pode começar a aplic�-los em seus projetos, mesmo que em pequenos pedaços, quanto antes voc� praticar, mais r�pido ir� dominar e evoluir no assunto.

Al�m disso, pode começar a pesquisar a respeito de boas pr�ticas de desenvolvimento orientado a objetos como, por exemplo, os princ�pios SOLID, GRASP e o DDD.

A orientaç�o a objetos � um pilar do desenvolvimento de software atual e as linguagens mais utilizadas hoje se baseiam neste pilar. Dominando os fundamentos da orientaç�o a objetos ficar� muito mais f�cil para voc� aprender C#, Java e qualquer outra linguagem O.O.

Confira tamb�m

Cursos de Engenharia de Software

Curso

An�lise e Projeto Orientado a Objetos

Curso

Guia de Orientaç�o a objetos

Guia

Fundamentos b�sicos da Orienta��o a Objetos

Este artigo trata sobre os principais fundamentos da orientação a objetos em C# explicando os conceitos de abstração, herança e polimorfismo.

Guia do artigo:

Fundamentos b�sicos de Orientaç�o a Objetos

Programaç�o estruturada VS Programaç�o Orientada a Objetos

Tipos de Refer�ncia x Tipos de Valor

Class x Struct

Herança

Virtual x Override

Modificadores de Acesso

Modificador Abstract

Modificador Sealed

Modificador Partial

Conclus�o

Confira tamb�m

Cursos de Engenharia de Software

An�lise e Projeto Orientado a Objetos

Guia de Orientaç�o a objetos

Artigos relacionados