Guia Linguagem C#

Abstração e polimorfismo na prática

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (12)  (0)

Este artigo apresenta importantes fundamentos da programação orientada a objetos com C#, como herança, abstração e polimorfismo, aplicados em um exemplo prático.

Artigo do tipo Tutorial
Recursos especiais neste artigo:
Conteúdo sobre boas práticas.
Abstração e polimorfismo na prática
Este artigo apresenta importantes fundamentos da programação orientada a objetos com C#, como herança, abstração e polimorfismo, aplicados em um exemplo prático. Usando boas práticas, veremos como estes fundamentos podem tornar um software mais fácil de ser mantido e evoluído, usando algumas técnicas de desenvolvimento ágil, como a refatoração. Veremos como resolver problemas comuns encontrados em código fonte (os chamados bad smells, ou “mau cheiros”), usando uma abordagem de desenvolvimento corretiva e evolutiva. Uma introdução ao desenvolvimento ágil evolutivo é apresentada, como forma de unir estas técnicas de orientação a objeto com as técnicas atuais de engenharia de software, demonstradas em um exemplo com C# e Visual Studio 2013.

Em que situação o tema é útil
As técnicas aqui apresentadas são úteis para construir softwares mais fáceis de serem mantidos e evoluídos ao longo do tempo, promovendo reutilização de código, reduzindo acoplamento entre classes, minimizando a ocorrência de bugs, tornando mais fácil a implementação de novos requisitos e tornando o código mais fácil de ser entendido.

No documento “The new Methodology” [4], Martin Fowler traz uma excelente visão sobre um novo estilo de desenvolvimento de software, baseado em metodologias ágeis. Metodologias tradicionais de engenharia de software, focadas em planejamento, têm sido utilizadas ao longo do tempo. O grande problema é que elas são muito burocráticas, dão ênfase em contratos fixos, documentação excessiva, vasto planejamento antecipado (prematuro). Essa abordagem não condiz mais com a realidade da maioria dos projetos na área de tecnologia, onde novos requisitos são criados, modificados ou mesmo removidos após um planejamento inicial. Processos e metodologias modernas, como as metodologias ágeis de desenvolvimento, são evolutivos por natureza. Organizam o trabalho de forma interativa, realizado em pequenas partes, com pequenas entregas (design, código, teste, documentação), liberadas aos poucos, ao invés de um único release enorme. Dão maior ênfase na colaboração e comunicação aberta e fluente entre stakeholders, clientes e membros do time, minimizando as chances de insucesso em projetos. Os princípios básicos da abordagem ágil sugerem que indivíduos e interações são mais importantes que processos e ferramentas, trabalho deve ser feito mais focado no software em si que em uma documentação abrangente, colaboração do cliente mais que negociação de contrato e, principalmente, responder a mudanças mais que seguir um plano.

O problema é que as abordagens tradicionais de engenharia de software se baseiam em outros ramos de engenharia, como a civil e mecânica, onde os custos com planejamento são menores. Em software, estima-se que até 50% de custos são gastos com design e planejamento. Projetos com um escopo invariável são raros, e se requisitos constantemente mudam, há um grande desperdício de esforço com análise que é descartada em virtude disso. Trabalho, tempo e dinheiro que são preciosos são perdidos. Uma abordagem ágil garante que a equipe e projeto sejam capazes de se adaptar às mudanças que ocorrerão, dentro de um contexto evolutivo.

A XP – Extreme Programming, uma abordagem ágil, prega cinco valores principais: comunicação, feedback, simplicidade, coragem e respeito, com foco maior em disciplina do que processos. Já Scrum prega um desenvolvimento ágil baseado em iterações chamadas sprints e reuniões de acompanhamento frequentes (meetings). Aplicações reais precisam continuamente ser evoluídas, novos requisitos implementados, melhorias devem ser feitas no projeto existente (design), algumas vezes é necessário mudar de tecnologia ou plataforma, corrigir bugs, otimizar e melhorar a performance. Isso remete a uma pergunta: O que pode ser considerado um “bom software”? Um bom software é aquele que funciona como planejado, mas depende do seu negócio. Para pequenas companhias (startups), bons softwares devem ser criados rapidamente. Para grandes corporações, o foco na construção de um software é torná-lo fácil de ser mantido ao longo do tempo. Nesse sentido, é necessário tomar cuidado com bons princípios de design, como criar componentes com baixo acoplamento, reutilizáveis, que garantam que alterações em componentes não afetam outros, que objetos tenham responsabilidades únicas, separadas, partes facilmente substituíveis, complexidade encapsulada. Esses são princípios básicos da programação orientada a objetos que, vistos dentro de um contexto de uma abordagem ágil evolutiva, vão tornar o sistema de software mais fácil de testar, evoluir, manter e entender. Padrões de Projeto (Design Patterns) [1] ajudam a criar bons designs de software, já o uso de refatoração [2] contínua (outra técnica amplamente divulgada por Fowler) garante código claro, limpo e funcional em equipes que programam de forma mais ágil, sem se preocupar em um primeiro momento com muitos aspectos de design, usando, por exemplo, Padrões de Projeto.

Padrões de Projeto são soluções reutilizáveis para problemas recorrentes no desenvolvimento orientado a objetos. Aplicar padrões antecipadamente em um projeto requer mais tempo e aumenta custos, ao mesmo tempo em que aumenta sua complexidade. Requisitos são modificados, criados ou mesmo eliminados conforme projetos evoluem. Tentar aplicar padrões antecipadamente para prever essas mudanças é um problema conhecido como excesso de engenharia [3]. Já projeto em escassez reduz custos, pois o sistema de software é criado rapidamente devido à falta de tempo, conhecimento ou necessidade de se adicionar funcionalidades em curto prazo. Ao longo do tempo, armazena-se um débito de projeto [3], que torna o sistema de software muito difícil de ser mantido e evoluído. É nesse contexto que entram as refatorações, como uma forma de melhorar o projeto existente sem alterar seu comportamento externo observável. Refatoração é o aspecto-chave para um projeto evolutivo, e é na evolução que se encontra a verdadeira sabedoria. Nesse caso, desenvolvimento ágil, evolutivo, incremental, apoiado em refatorações e testes, é uma excelente receita para garantir o sucesso do projeto, seja ela para um startup ou uma grande corporação.

Este artigo vai mostrar como aplicar estes conceitos em um exemplo prático com C# e Visual Studio 2013. Serão demonstrados os principais fundamentos da orientação a objetos (ver BOX 1) em uma aplicação que simula notificação de clientes de uma determinada companhia, por exemplo, uma operadora de telefonia, que precisa avisar seus clientes sobre cobranças, promoções e lançamentos. Além dos fundamentos da orientação a objetos, são demonstradas importantes técnicas como programação para interfaces, padrões, anti-patterns, bad smells [2] e uso contínuo de refatoração para um desenvolvimento ágil com código sempre limpo e funcional.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?