Desenvolver sistemas é
mais do que criar classes a esmo, formulários e colocar tudo ali. É pensar no
problema, possíveis soluções e unir tudo em algo que não cause mais problemas.
Por isso existem os bons princípios para desenvolvimento de softwares orientados
a objetos. Neste artigo vamos estudar como separar a camada de interface do
restante do aplicativo. Desenvolver um sistema
flexível é bom para você, como desenvolvedor, e bom para seu cliente. Para você
é bom porque levará menos tempo para ajustar o sistema e o fará com segurança.
Para seu cliente é bom porque ele verá que o sistema que ele utiliza é estável
e que não vai deixá-lo na mão. Resumo DevMan: Criar uma separação entre
as camadas lógicas de um aplicativo é muito bom, desde que se evite dependência
excessiva entre as classes, duplicação de código e outros problemas mais. Neste
artigo vamos estudar o padrão MVVM e com um exemplo prático ele será aplicado
para que você leitor assimile e possa utilizar no seu dia-a-dia.
Em que situação o tema é útil:
O desenvolvimento para dispositivos móveis sempre foi considerado um desenvolvimento diferenciado, seja por restrições do hardware ou recursos disponíveis da linguagem utilizada. A plataforma .NET diminuiu essas diferenças quando lançou na época o .NET Compact Framework, que permitia ao desenvolvedor usufruir de recursos de forma mais fácil. O próprio sistema operacional móvel da Microsoft sofreu mudanças ao longo do tempo, e hoje uma nova e remodelada plataforma nasce, o Windows Phone. Esta evolução aproveita todo o conhecimento em XAML do desenvolvedor, mais os recursos do .NET Framework, aliados a um único ambiente de desenvolvimento. É o sonho de consumo de qualquer desenvolvedor, que agora pode aplicar os mais diversos recursos do ambiente, incluindo o uso da orientação a objetos em si (ler Nota DevMan 1).
A orientação a objetos surgiu com a necessidade de se criar um paradigma de programação simples baseado na percepção humana dos objetos ao seu redor. Este novo paradigma não é apenas um modo de programar, mas uma maneira de pensar e conceber as ideias. Neste paradigma, o software é composto por uma coleção de objetos que interagem entre si através de mensagens, simulando as ações que ocorrem no mundo real.
A partir dos conceitos do paradigma orientado a objetos é possível fazer uma análise dos requisitos do sistema, investigando as entidades que o compõem. O sistema pode ser quebrado em unidades de objetos e a partir daí é possível entender como eles se relacionam. Nesta etapa será feita a análise de requisitos para serem construídos modelos que representem o sistema.
O importante é o que será feito, sem se preocupar em como será feito, desprendendo-se de qualquer tipo de tecnologia. O sistema assim precisa ser validado e verificado, para ter certeza de que os requisitos atendem as necessidades do cliente.
Em um processo de desenvolvimento orientado a objetos, o resultado da analise são modelos que representam as estruturas das classes de objetos componentes e modelos que especifiquem as funcionalidades do sistema. A ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema. Por exemplo, num sistema acadêmico alguns dos conceitos poderiam ser “aluno”, “matricula”, “curso”.
A utilização deste mecanismo possibilita não somente à equipe de desenvolvimento o entendimento do problema. Como este paradigma aproxima o mundo real do computacional, ele traz também como benefício uma melhor interpretação do cliente quanto ao documento de requisitos especificado.
Sempre se fala da orientação a objetos como se esta fosse a bala de prata para todos os problemas, desde análise à programação. No entanto, apesar de podermos desenvolver para o Windows Phone aplicando a orientação a objetos, colocar tudo em classes não resolve o problema, podendo até mesmo piorar a situação, pois um software orientado a objetos mal construído é sinônimo de dor de cabeça.
Neste momento estamos considerando que todo leitor já sabe o que é uma classe, uma propriedade, um método. Já conhecem estruturalmente a orientação a objetos, e o que falta é saber como modelar tudo isso de forma adequada para poder criar um sistema flexível e que responda rápido às mudanças das regras de negócio.
As regras de negócio mudam constantemente, isto é fato, e faz com que seja um desafio construir um aplicativo que responda rápido às mudanças apresentadas. Toda essa exigência por mudanças pode levar-nos a desenvolver algo que não tenha a qualidade desejada. Os aplicativos bem desenvolvidos podem oferecer vantagem competitiva para seus clientes, contudo o projeto mal modelado pode levar a prejuízos por enrijecer processos, já que não se adapta às mudanças de forma eficiente. Neste segmento, é possível identificar quando um aplicativo é bem ou mal projetado, por isso vamos analisar os elementos de um bom design e de um não tão bom.
Modelagem boa
Aplicações bem desenhadas oferecem rotinas que são robustas, de fácil manutenção e reutilizáveis. Elas devem estar aptas a se adequar às mudanças sem afetar sua modelagem. Um exemplo disso seria uma aplicação onde é necessário exportar um arquivo em um determinado formato. Adicionar novos formatos ao sistema atual deve ser uma tarefa fácil.
As três características de um bom design são:
• Manutenção – Facilidade com que um sistema pode ser alterado para aplicar novas regras de negócio, mas não apenas regras, como também melhorar seu desempenho, corrigir falhas e outras solicitações. Aplicações que possuem um bom design exigem poucos recursos (tempo, esforço e até mesmo capital) para realizar sua devida manutenção;
• Reusabilidade – Em um sistema bem projetado é possível que os seus componentes possam ser reutilizados por outros sem grandes dificuldades;
• Robustez – Estabilidade do sistema em situações extremas, do tipo: tratamento de entradas erradas por parte de usuários e carga máxima de dados em determinado momento do dia.
Modelagem ruim
Ninguém desenvolve um software com problemas de projeto porque quer. Isso é decorrência da inexperiência ou de uma modelagem feita às pressas para atender a um tempo limite de entrega.
Sistemas construídos dessa maneira costumam apresentar os seguintes problemas:
• Rigidez – Dizemos que um sistema é rígido quando uma alteração nele é difícil. E essa alteração é considerada difícil porque rotinas internas estão, muito provavelmente, entrelaçadas a um ponto onde alterar qualquer coisa leva a uma cascata de alterações. Nessas situações, quando o sistema fica grande, é difícil estimar o prazo para uma alteração, já que todo o impacto deve ser medido antes;
• Fragilidade – Por ter rotinas muito ligadas umas às outras, a alteração em uma leva a problemas nas outras. Quem aqui nunca alterou algo em um sistema que depois causou um problema em uma parte que parecia não estar relacionada com a alteração feita? Corrigir esse tipo de problema pode levar a outros, desencadeando uma leva de ajustes que custam tempo e, consequentemente, dinheiro. Um sistema nessa situação perde sua credibilidade, pois vive em contenção de erros, impedindo que seus desenvolvedores mantenham uma qualidade futura ao projeto;
...
