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. Em que situação o tema é útil: 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.
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).
Nota DevMan 1. Orientação a Objetos
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. "
[...] continue lendo...