Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
MVVM no Windows Phone - Revista Mobile Magazine 39
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 softw
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da 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).
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;
· Reusabilidade – Neste caso, a falta da mesma. Quando for preciso reutilizar alguma rotina, o trabalho pode ser tão difícil que é menos custoso desenvolver novamente essa rotina.
Agora que vimos como se parece, do ponto de vista arquitetural, um bom sistema e um ruim, vamos conhecer alguns princípios que podem determinar o sucesso de um design de software.
Seja S.O.L.I.D.
Esta sigla é um acrônimo para a palavra em inglês “solid”, que significa sólido, solidez. Cada letra representa um acrônimo de um princípio, ou seja, temos um acrônimo de um acrônimo. Esse conjunto é o resultado de estudos e experiências de vários desenvolvedores, e foi primeiramente catalogado por Robert “Uncle Bob” Martin (veja seção Links), em seu livro “Applying Principles and Patterns”. Vamos tratar aqui do primeiro princípio.
Single Responsability
Principle (SRP)
Este é o princípio da responsabilidade única, que recomenda que uma classe só deva ter um motivo para sofrer alguma alteração. Sendo assim, podemos resumir que uma classe qualquer em seu sistema deva ter uma tarefa única e específica. Isso, contudo, não quer dizer que se tenha apenas um único método, mas que todos os métodos criados trabalhem juntos em um único objetivo: atender a responsabilidade da classe. Outros autores também chamam este princípio de coesão.
Para entendermos seu significado vamos imaginar um cenário que todos conhecem. Digamos que você desenvolveu um sistema e nele construiu uma interface muito bonita. Nos eventos de clique dos botões você acessa um banco de dados, monta consultas SQL, executa relatórios e tudo mais. Ou seja, tudo está codificado de tal forma que além de ter que exibir informações, essa tela agora também precisa acessar banco de dados, executar SQL e muito mais. Se pararmos para pensar, você acha que é responsabilidade da UI saber tudo isso? Apesar da forma que foi construída, temos essa classe que gerou a tela lidando com mais de uma situação e responsabilidades diferentes. Se amanhã a estrutura do banco de dados é alterada, é preciso corrigir a classe. Se também algo muda na regra de negócio referente a um campo que deva ser exibido, essa classe também precisa ser corrigida, ou seja, temos aqui mais de um motivo para essa classe ser alterada e isso não é bom. Não é bom porque cada responsabilidade é um arco de mudanças, que muito provavelmente estão entrelaçadas. Estamos falando aqui de responsabilidade, mas o que é isso para uma classe?
No contexto deste artigo, ela representa um motivo de mudança. Nem sempre é fácil identificar responsabilidades a mais em uma classe, isso porque estamos acostumados a ver um sistema como um todo, não distinguindo suas camadas. Tudo isto se aplica também ao desenvolvimento de aplicativos móveis.
Separando em camadas
"ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Space do autor
0
0
