Imprimir Post

Programação Orientada a Objetos com C# (Parte 4.13) – Herança

Resumo:

O objetivo não se aplica a este post.

Uma vez que o conteúdo total desta série foi dividido em partes, deve-se considerar absoluto o resumo da primeira postagem até o momento presente.

Herança - Relembre - Link Primeiro Post

Este tema da série Programação Orientada a Objetos com C# irá demandar mais publicações. Sendo assim, a numeração sequencial desta parte da série passou de 4.12 para 4.13 (vide título) e assim seguirá (4.14, 4.15…) mediante a necessidade de conclusão.

Palavras-chaves:

Variáveis, Propriedades, Modificador, Acesso, Classe, Objeto.

Texto:

Mãos a Obra

Com a alteração das classes UnicoComum e Program, aplicando Herança à partir de uma nova categoria de Bilhetes (vide post anterior), o próximo passo na Programação Orientada a Objetos com C# será dar continuidade a estes assuntos e suas variantes, vistas até o momento presente.

Herança - Relembre - Link Post Anterior

Adendo

Para realização do Post foram utilizados os seguintes Programas:

  • Windows 7 Ultimate;
  • Microsoft Visual Studio 2010 Ultimate SP1 (Service Pack 1).

A única configuração realizada após a instalação dos programas acima, foi manter o Microsoft Visual Studio sendo executado como usuário Administrador do Sistema Operacional, a fim de evitar maiores problemas.

Recapitulando o avanço

Sobre o eixo da Herança, ao recapitular o avanço estabelecido no cenário até o momento, tem-se:

  • Classes Unitario e EspecialDesempregado são o que se conhece como Bilhetes de Metrô:
Herança - Classe Unitario x Classe EspecialDesempregado

Classe Unitario x Classe EspecialDesempregado

  •  A partir deste ponto de análise, surge em necessidade a classe Bilhete que é a classe Pai ou Base, criada para armazenar e centralizar as características em comum de Unitario e EspecialDesempregado:
Herança - Classe Unitario x EspecialDesempregado x Bilhete

Classe Unitario x EspecialDesempregado x Bilhete

  • Unitario e EspecialDesempregado são classes Filhas ou Descendentes, pois herdam da classe Bilhete. Além disto, Bilhete passa a deter suas características em comum (antes definidas em suas próprias estruturas de classes): 
Herança - Classes Descendentes Herdando da Classe Pai Bilhete

Classes Descendentes Herdando da Classe Pai Bilhete

  • Com a evolução do cenário, surge uma nova categoria de bilhetes, chamada Bilhete Único. Esta categoria visa o armazenamento créditos, havendo recargas ou débitos mediante a sua utilização como passagem.
  • Na prática, a representação do Bilhete Único se inicia com a criação da classe UnicoComum, levando em seu código um controle de saldo independente, diferentemente da classe Unitario por exemplo, que utiliza-se da classe Bilhete como base de cálculo não acumulativa:
Herança - Classe UnicoComum

Classe UnicoComum

  • Redesenhando o código como boa prática da Orientação a Objetos, a fim de garantir a divisão correta de responsabilidades, verifica-se como resultado final da classe UnicoComum:
Herança - Classe UnicoComum

Classe UnicoComum

Apresentando uma nova situação

Nota-se até o momento portanto, que a classe UnicoComum trabalha de maneira particular com o seu controle de saldo através dos métodos Saldo() e Debita(), aproveitando da classe Herdada Bilhete o valor da tarifa padrão (método base.CobraTarifa()), resultado da utilização de uma passagem de metrô:

Herança - Classe UnicoComum

Classe UnicoComum

Supondo que, um usuário tenha se locomovido de ônibus até o metrô, mas ainda não tenha acessado este último (no caso, as linhas de ônibus possuem um sistema de passagem que também dá suporte a utilização de Bilhetes Únicos).

Logo, quando um usuário utiliza um ônibus com um Bilhete Único Comum, no primeiro momento do dia é cobrada uma tarifa de R$3,80 e, caso em um tempo limite de 2 horas ele utilize este mesmo bilhete em um metrô, serão cobrados R$5,92. Este fato é popularmente conhecido como Integração.

Retornando o cenário prático, para implementar esta nova regra, é necessário entender que o débito de uma passagem deverá ser realizado com uma tarifa própria a condição de integração dentro da classe UnicoComum e não somente a realização do débito através de uma tarifa aproveitada por herança obtida da classe Bilhete.

Considerações Finais:

Visando a Introdução e apresentação de um novo aspecto no cenário estabelecido até o momento, coloca-se em destaque a dúvida que basicamente se resume em:

“Como implementar a Integração para um Bilhete Único Comum”?

Essa dúvida irá garantir ao longo dos próximos posts, um panorama que reflita na memória do leitor, todos os outros assuntos desbravados até este ponto do tema.

Na próxima publicação, ainda quarta parte da série: Programação Orientada a Objetos com C# será apresentado o décimo quarto post sobre Herança, o leitor irá conferir a continuidade do tema entre outros aspectos relevantes a este assunto.

Referências Bibliográficas:

As referências bibliográficas serão apresentadas no último post desta série.

Sobre o autor

Thiago Richard Vanicore

Thiago Richard Vanicore formou-se em análise e desenvolvimento de sistemas, possui certificação ITIL Foundation V2 e entre seus conhecimentos estão: ASP .Net (WebForms/MVC5/Web API) C#, HTML5, Html/XHtml, CSS3, JQuery, JQuey Mobile, JavaScript, Xml, Ajax, Json, Microsoft SqlServer, MySql, Firebird, Azure, Visual Studio Online, Scrum, UML, CRM, Quality Assurance, CTI (Computer Telephony Integration) MPSBR (Melhoria de Processos do Software Brasileiro).

Link permanente para este artigo: http://linksinergia.com.br/2016/05/04/programacao-orientada-a-objetos-com-c-parte-4-13-heranca/