Profissionais TI - Pra quem respira informação

Olá, leitores!

Nos artigos anteriores sobre dicas de desenvolvimento, foquei bastante em aspectos técnicos, visuais e comportamentais de um software (leia: Parte 1, Parte 2, Parte 3, Parte 4, Parte 5, Parte 6, Parte 7, Parte 8). Neste artigo, vou abordar assuntos mais conceituais que fazem parte da minha paixão por TI: Engenharia e Arquitetura de Software.

A partir do momento que tomei conhecimento e comecei a praticar os conceitos citados neste artigo, notei uma grande diferença na minha produtividade e na qualidade do software. Provavelmente estes conceitos não serão novidade para muitos, mas é interessante deixá-los registrados como parte dessa série de artigos.

Design Patterns

Os Design Patterns, ou Padrões de Projeto, como são conhecidos, são conceitos ou modelos orientados a objetos visando solucionar problemas no desenvolvimento de softwares. Estes padrões possuem finalidades particulares que podem ser aplicadas para controlar a estrutura, a criação e o comportamento das classes e dos objetos em uma aplicação. Dependendo da situação em que esses projetos forem aplicados, é possível notar uma redução considerável na complexidade do software em virtude da reutilização de código-fonte e de componentes.

Este ano, por exemplo, acompanhei a implementação dos padrões de projeto Singleton, Strategy, Observer, Builder e Factory Method em um projeto na empresa em que trabalho e pude observar as vantagens que estes padrões trouxeram ao código-fonte, bem como a facilidade para compreender e documentar o software.

Apesar de existir 23 padrões de projeto, é praticamente inviável implementar todos eles em uma única solução, afinal, utilizar padrões de projeto sem um propósito é uma má prática. É preciso haver um motivo real para a implementação, ou seja, uma situação em que se pode comprovar de que o padrão de projeto será uma solução adequada para o problema. Caso contrário, a implementação pode aumentar a complexidade do programa e afetar também o desempenho da aplicação.

Uma das dúvidas mais frequentes relacionadas a padrões de projeto é saber onde, quando e como utilizá-los. Em primeiro lugar, o engenheiro de software deve ter sólidos conhecimentos em Programação Orientada a Objetos e um bom nível de abstração, ou seja, a Orientação a Objetos é a base essencial para compreender os padrões de projeto. Em segundo lugar, é necessário conhecer o objetivo principal de cada padrão de projeto para que seja possível fazer um estudo da viabilidade para solucionar um problema no software. No entanto, mesmo com esse conhecimento técnico, é comum alguns engenheiros não conseguirem identificar as situações ou os módulos que devem receber a implementação dos padrões. Portanto, em terceiro lugar, o profissional também deve ter um domínio satisfatório da regra de negócio do cliente. A consolidação de todas essas experiências é o que permite a seleção e a aplicação consciente dos padrões de projeto no desenvolvimento do software.

Padrão de arquitetura

Um bom software deve proporcionar flexibilidade e facilidade de manutenção. São inúmeros os casos de softwares que foram desenvolvidos sem uma estrutura bem definida e, após algum tempo, apresentaram complicações nas atividades de manutenção. Por conta disso, os padrões de arquitetura são modelos que surgiram para definir a estrutura do software visando não somente a facilidade da manutenção, mas também outros aspectos, como a modularização, desempenho, agilidade no build e a divisão de responsabilidades em camadas.

O MVC (Model-View-Controller) é um dos padrões de arquitetura disponíveis no mercado e amplamente utilizado. Além do MVC, há também outros padrões populares, como o MVP (Model-View-Presenter) e o MVVM (Model-View-View-Model). Apesar da diferença nas nomenclaturas, a ideia central desses três padrões de arquitetura é basicamente a mesma: separar a lógica e a apresentação dos dados em camadas (ou níveis) diferentes. Enquanto a camada Model representa a modelagem dos dados (classes, métodos, persistência), a camada View é responsável por exibir estes dados ao usuário. Por fim, a camada intermediária, diferente para cada padrão (Controller, Presenter ou View-Model), tem a função de gerenciar a comunicação entre a Model e a View.

Embora estes padrões apresentem o conceito de três camadas, nada impede que você “estenda” essas camadas para expandir a dimensão do projeto. Por exemplo, alguns desenvolvedores preferem manter as classes do projeto (modelagem) e o acesso ao banco de dados em camadas diferentes. Sendo assim, cria-se uma camada estendida da camada Model para o acesso ao banco de dados, conhecida como DAO (Data Access Object) ou DAL (Data Access Layer). Trata-se de uma camada simples, apenas com os objetos de conexão com o banco de dados e as instruções SQL, mas que, dependendo do contexto, pode proporcionar uma melhor organização na estrutura da aplicação.
Deixo aqui a minha recomendação: procurem estudar e conhecer melhor sobre estes padrões de arquitetura. Os conceitos são bastante interessantes e a implementação definitivamente traz bons resultados!

Clean Code

Uma vez li a seguinte frase em um fórum de programação:

“Código ruim não é ruim, é apenas mal compreendido.”

Francamente, não concordo com essa frase. Se todos os programadores pensarem dessa forma, haverá tantos códigos peculiares nos softwares que, em certo momento, será impossível compreendê-los. Para evitar o código ruim e contornar a frase acima, existe um conceito chamado Clean Code. Em linhas gerais, como o próprio nome sugere, Clean Code significa “código limpo” e orienta a como escrever um código estruturado, organizado e compreensível.

O conceito de Clean Code envolve várias práticas que podem ser aplicadas por qualquer desenvolvedor para escrever um código melhor. Entre essas práticas, há recomendações sobre como definir nomes de funções, nomes de variáveis, responsabilidades de métodos (um método deve ter uma e somente uma responsabilidade), indentação de código, parâmetros e até mesmo orientações de como escrever comentários (e anotações) no código-fonte.

Há um ótimo livro escrito por Robert C. Martin chamado “Clean Code – A Handbook of Agile Software Craftsmanship” que aborda todas essas práticas de forma bem detalhada e didática, inclusive com bastantes exemplos. Ainda não tive a oportunidade de lê-lo por completo, mas já consultei algumas páginas para estudar melhores formas de aprimorar alguns pontos do meu código e me identifiquei com o conteúdo. Na verdade, depois de conhecer este livro e ler vários artigos na internet sobre este assunto, pude perceber o quanto o comprometimento na escrita do código-fonte é importante para o desenvolvimento de software.
Isso nos leva a refletir sobre aquela famosa frase: “Você é responsável pelo seu código!”.

Interfaces

Se você tem conhecimento ou experiência com Programação Orientada a Objetos, provavelmente já ouviu falar ou trabalhou com Interfaces. Na verdade, essa palavra tem uma ambiguidade na área de TI e pode confundir o profissional que trabalha com programação. A palavra “Interface” pode ser usada para se referir ao visual de uma aplicação, um componente de hardware (por exemplo, interface de rede), como também um recurso na Orientação a Objetos, no qual é o objetivo deste tópico.

Uma Interface é um recurso que nos permite determinar comportamentos em comum entre classes que a implementam. Por meio de sua utilização, é possível estabelecer um padrão na implementação de métodos entre classes como se houvesse um tipo de “contrato”. Em outras palavras, as classes que implementam uma determinada Interface deve obedecer todos os métodos assinados por ela, garantindo um nível adequado de padronização.

Suponha que criamos uma Interface e definimos duas assinaturas de métodos que serão utilizados no formulário de clientes: DescontarValor e ValidarDocumento. Vale ressaltar que na Interface não há implementação destes métodos, apenas a assinatura. Em seguida, criamos as classes ClienteFisico e ClienteJuridico que implementam a Interface que acabamos de criar. Por convenção, essas duas classes devem obrigatoriamente implementar os métodos DescontarValor e ValidarDocumento, já que elas possuem um contrato com a Interface. Porém, como as classes são diferentes, a implementação destes métodos será diferente para cada uma delas. Para a pessoa física, o desconto do valor será de 2% e a validação do documento deverá ocorrer pelo CPF da pessoa. Por outro lado, para a pessoa jurídica, o desconto será de 4% e a validação irá verificar o CNPJ da empresa. Mesmo que sejam finalidades diferentes, os nomes dos métodos são os mesmos e a implementação é obrigatória. Se futuramente for necessário incluir um novo método na Interface, como, por exemplo, VerificarCredito, este deverá ser codificado em cada classe que implementa a Interface.

As vantagens de se utilizar Interfaces se resumem essencialmente na organização e nivelamento de classes, na reutilização de componentes do software e na facilidade de manutenção (em virtude da flexibilidade). O conceito de Interfaces é utilizado com bastante frequência na implementação de Design Patterns e de padrões de arquitetura, portanto, é muito importante conhecê-lo. Como se pode notar, estes conceitos estão estritamente ligados um ao outro, o que facilita a compreensão e expande a linha de raciocínio para profissionais que trabalham com Orientação a Objetos.

Agradeço novamente pela visita, leitores!
Abraço!

Leia também: Parte 1, Parte 2, Parte 3, Parte 4, Parte 5, Parte 6, Parte 7, Parte 8, Parte 10, Parte 11

Publicado originalmente no blog SubRotina