MVVM no Windows Phone - Revista Mobile Magazine 39

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. "