Um princípio fundamental que deve ser adotado na criação de aplicativos multiplataforma é criar uma arquitetura que se presta a uma maximização do compartilhamento de código entre as plataformas.

Para poder fazer isso você já deve ter experiência e conhecimento dos conceitos chaves da Programação Orientada a Objetos (POO), dos conceitos relacionados com a separação de responsabilidades em camadas e ter conhecimento dos padrões de projetos usados na construção de um aplicativo bem arquitetado.

Vejamos a seguir um resumo de cada uma desses tópicos.

Conceitos Chaves da Programação Orientada a Objetos - POO

1- Encapsulamento

A aplicação do encapsulamento garante que as classes e até mesmo as camadas da arquitetura só exponham uma API mínima que executa as suas funções necessárias, e esconde os detalhes de implementação.

A nível de classe, isto significa que os objetos se comportam como "caixas pretas" e que o código não precisa saber como ele vai realizar as suas tarefas.

A nível de arquitetura, significa implementar padrões como Facade que incentivam uma API simplificada que orquestra interações mais complexas em nome do código nas camadas mais abstratas. Isto significa que o código da UI (por exemplo) só deve ser responsável por exibir telas e aceitar a entrada do usuário; e nunca interagir com a base de dados diretamente. Da mesma forma o código de acesso a dados só deve ler e escrever para o banco de dados, e nunca interagir diretamente com botões ou etiquetas da UI.

2- Separação de Responsabilidades

Ao projetar e desenvolver um software procure sempre aplicar a separação de responsabilidades que é o processo de dividir sua aplicação em unidades específicas de funcionalidades de tal forma que cada unidade atenda somente às necessidades de sua responsabilidade, tendo o mínimo de sobreposição possível com outras unidades em termos de funcionalidade; ou seja, nenhum elemento do sistema deve compartilhar as responsabilidades de outro ou abranger responsabilidades não relacionadas.

Isto é alcançado estabelecendo limites, onde um limite é qualquer restrição lógica ou física que delimita um determinado conjunto de responsabilidades.

Certifique-se de que cada componente, tanto a nível de arquitetura como a nível de classe, tenha um objetivo claro e bem definido. Cada componente deve executar apenas suas tarefas definidas e expor essa funcionalidade através de uma API que seja acessível para as outras classes que precisam usá-lo.

3- Polimorfismo

Polimorfismo significa muitas formas, e, na orientação a objetos você pode enviar uma mesma mensagem para diferentes objetos e fazê-los responder da maneira correta. Você pode enviar a mensagem mover para cada objeto semelhante a um veiculo e cada um vai se comportar de maneira diferente para atender a sua solicitação.

 

Quando uma mesma mensagem pode ser processada de diferentes formas temos um exemplo de polimorfismo.

Programar para uma interface ou classe abstrata que suporta múltiplas implementações significa que o código do núcleo pode ser escrito e compartilhado entre plataformas, enquanto ainda interage com recursos específicos da plataforma.

4- Padrões de Projetos

Padrões de projeto podem ser vistos como uma solução que já foi testada para um problema. Desta forma , um padrão de projeto geralmente descreve uma solução ou uma instância da solução que foi utilizada para resolver um problema específico. Padrões de projetos  são soluções para problemas que alguém um dia teve e resolveu aplicando um modelo que foi documentado e que você pode adaptar integralmente ou de acordo com necessidade de sua solução.

Aplicando padrões de projeto você ganha tempo e torna sua aplicação mais fácil de manter, testar e usar.

A aplicações desses princípios tem como resultado natural aplicações modeladas com base no mundo real ou entidades abstratas com camadas lógicas distintas.

A separação de código em camadas faz com que as aplicações sejam mais fáceis de entender, testar e manter.

Recomenda-se ainda que o código em cada camada seja fisicamente separado, tanto em diretórios ou até mesmo projetos separados para aplicações muito grandes, bem como logicamente separadas (utilizando namespaces).

E por falar em camadas vamos ver quais os principais tipos de camadas usados em aplicações móveis.

Tipos de Camadas mais usadas em aplicações

A seguir vou dar um resumo dos tipos de camadas mais usados na arquitetura de aplicações :

a- Camada de Dados

A persistência de dados não volátil; provavelmente  deve ser usado um banco de dados SQLite, mas poderia ser implementada com arquivos XML ou qualquer outro mecanismo adequado.

b- Camada de Acesso aos Dados  - Data Access Layer (DAL)

Envolve a camada de dados que realiza as operações de de acesso aos dados como criar, ler, atualizar, excluir (CRUD) , sem expor detalhes de implementação para o chamador. Por exemplo, a DAL pode conter instruções SQL para consultar ou atualizar os dados, mas o código de referência não precisa saber disso.

c- Camada de negócios - Businness Logic Layer (BLL)

Ás vezes chamada de camada de lógica de negócios ou BLL, contém definições de entidade de negócio (o modelo) e lógica de negócios.

d- Camada de Acesso a Serviço - Service Access Layer

Usada para acessar serviços na nuvem : a partir de complexos web services (REST, JSON, WCF) ou de uma simples recuperação de dados e imagens a partir de servidores remotos. Encapsula o comportamento de rede e fornece uma API simples para ser consumida pelas camadas de aplicação e interface do usuário.

e-  Camada de Aplicação - Application Layer

Representa o código que é normalmente específico de cada plataforma (geralmente não compartilhado entre as plataformas) ou código que é específico para o aplicativo (que geralmente não são reutilizáveis). Um bom teste para saber se você deve colocar o código na camada de aplicação ou na camada de interface do usuário é : 

•  Determinar se a classe tem quaisquer controles reais de exibição;
•  Verificar se ele poderia ser compartilhado entre várias telas ou dispositivos (ex. IPhone e iPad );