Entender a separação de preocupações
Objetivos de aprendizagem
Após concluir esta unidade, você estará apto a:
- Explicar o valor comercial de adotar a separação de preocupações.
- Usar a SOC para adaptar sua solução às alterações nos requisitos do usuário ou nas tecnologias da plataforma.
- Aplicar a SOC ao desenvolvimento do Force.com.
- Determinar quando aplicar a SOC.
Introdução
O software, tal como os cortes de cabelo, é geralmente considerado como algo vivo que muda e evolui com o tempo. Desde a ameba unicelular de um programa “Hello World” à complexidade de um software de nível empresarial, a longevidade e a diversidade da vida também ocorrem nos softwares. Organismos complexos desenvolvem sistemas para fins especializados. Esqueletos, músculos e órgãos trabalham como uma unidade, mas também interagem com outros sistemas para benefício mútuo.
O mesmo se aplica aos complexos aplicativos corporativos. Separar as várias preocupações em sistemas ou camadas diferentes facilita a navegação em códigos e a manutenção dos mesmos. Quando são feitas alterações, os impactos e regressões em outras áreas são minimizados e um programa mais íntegro e mais adaptável se desenvolve.
Acompanhar com o Trail Together
Deseja acompanhar um especialista enquanto trabalha nesta etapa? Veja este vídeo que faz parte da série Trail Together.
Separação de preocupações (SOC)
O urso Codey sempre diz, “O melhor código se escreve longe do teclado”. Essa é outra forma de dizer que um bom código se beneficia de um design cuidadoso e de perspicácia. Considere esta recomendação quando planejar onde colocar seu código. Escrever códigos deve ser fácil quando você sabe o caminho que vai seguir!
Códigos complexos saem de controle quando não são divididos adequadamente. Quando o código está muito misturado, ele se torna propenso a erros, difícil de manter e difícil de aprender. Já tentou depurar o código espaguete de alguém? E os problemas ainda pioram à medida que você vai juntando novos desenvolvedores! Criar módulos ou bibliotecas para compartilhar cálculos comuns e processos entre diferentes partes de seu aplicativo é geralmente a primeira etapa no reuso de códigos, o que é, obviamente, uma boa coisa!
Então a SOC é apenas uma palavra chique para reuso de código?
Sim e não. O termo SOC exige alguma reflexão sobre o encanamento interno de seu aplicativo, incluindo convenções de nomenclatura de classes e diretrizes de codificação. Você quer que esse planejamento resista e que seja, de certa forma, autodescritivo para outras pessoas. Um bom código deve contar uma história. A abordagem habitual para reuso de código é mover fragmentos de código assim que duas ou mais áreas precisarem. O código é geralmente colocado em classes MyUtil ou em alguma outra área de descarte genérica. O que é bom! E certamente é recomendado para copiar e colar!
Quais as vantagens da SOC?
Em um nível elevado, os aplicativos têm três características: armazenamento, lógica e um meio de interagir com eles, seja por meio de humanos, criaturas da floresta ou outros aplicativos. Quando você separa essas coisas, pode começar a definir camadas em seu aplicativo, cada uma com seu próprio conjunto de preocupações e responsabilidades face a outras camadas e ao aplicativo como um todo. A consideração e o gerenciamento cuidadosos dessas camadas são importantes para adotar a SOC.
- Evolução. Ao longo do tempo, conforme evoluem a tecnologia, o conhecimento e as exigências (funcionais e técnicas), uma camada pode precisar ser estendida, retrabalhada ou até descartada. Veja a tecnologia de IU dos últimos 10 anos como um excelente exemplo. Quantos frameworks de JavaScript você consegue contar antes de desmaiar?
- Gerenciamento de impacto. Modificar ou descartar uma ou mais camadas não deve afetar desnecessariamente outras camadas, a menos que esta seja a intenção face às exigências.
- Papéis e responsabilidade. Cada camada tem sua responsabilidade e não deve se isentar dessa responsabilidade nem ultrapassá-la. Por exemplo, desistir da tecnologia ou biblioteca de um cliente em favor de outro não significa perder a lógica de negócios, porque essa é a responsabilidade de outra camada. Se as linhas de responsabilidade não forem claras, o propósito e o valor da SOC são prejudicados, o que não é bom.
A plataforma Force.com tem duas abordagens distintas para desenvolvimento: codificação declarativa (apontar e clicar) e codificação tradicional. Você pode usar qualquer um dos métodos individualmente ou em conjunto. Essas duas abordagens se ajustam às camadas de SOC padrão conforme descrito abaixo.
Apresentação
- Declarativa: Layouts, fluxo, tipos de registro, fórmulas, relatórios, painéis
- Codificação: Controladores do Apex, Visualforce, componentes do Lightning
Camada de lógica de negócios
- Declarativa: Fórmula, fluxo, validação, fluxo de trabalho, regras de compartilhamento
- Codificação: Serviços do Apex, ações personalizadas do Apex
Camada de acessos a dados
- Declarativa: Data Loaders
- Codificação: SOQL, SOSL, APIs do Salesforce
Camada do banco de dados
- Declarativa: Objetos personalizados, campos, relacionamentos, totalizações
- Codificação: Acionadores do Apex
Quando não precisamos de SOC no Force.com
Uma das principais vantagens do Force.com é seu modelo de desenvolvimento declarativo que permite criar objetos, campos, layouts, regras de validação, fluxos de trabalho, campos de fórmula e muito mais sem escrever uma única linha de código. O desenvolvimento declarativo é mais rápido e fácil, e já implementa um grau de SOC. Se o seu aplicativo for essencialmente centrado em dados, você pode oferecer uma grande parte de seu aplicativo de modo declarativo, então não complique, seja prático!
Embora não seja código, o que você pode alcançar com o desenvolvimento declarativo ainda é somente uma camada de arquitetura em seu aplicativo e, sobre isso, falaremos mais adiante.
Quando usar a SOC no Force.com
Se o seu aplicativo é centrado em processos, ou se você está sendo pressionado para implementar mais cálculos complexos, validações ou experiências de IU mais rebuscadas, você estará se aventurando em território do código do Apex. O Force.com fornece muitos locais para colocar código do Apex, como acionadores, controladores do Visualforce, APIs, Apex em lote e manipuladores de email.
Você pode fazer um investimento enorme no desenvolvimento e teste do código, mas é a lógica de negócios que você estará mais preocupado em proteger. Iremos explorar algumas diretrizes para escrever lógica de negócios mais tarde, mas, por enquanto, considere as seguintes instâncias para usar a SOC no Force.com.
- Como substituir ou adicionar outra IU no seu aplicativo – Considere quanto código você precisa reescrever ou portar que não tem nada a ver com a IU mas afeta a inserção, atualização, validação e a funcionalidade de cálculo do seu aplicativo.
- Como fornecer uma API voltada para o público para sua lógica – Avalie quais partes de seu código existente você gostaria de chamar para implementar a API. O uso de seus métodos de ação nos seus controladores do Visualforce é uma boa base para uma API? (A resposta é não.)
- Como escalar a lógica do seu aplicativo por meio do Apex em lote – Se você precisa continuar fornecendo uma experiência interativa (para volumes menores) por meio de sua IU existente, como compartilharia lógica entre os dois para garantir que o usuário consiga resultados consistentes independentemente do tamanho?
- Como trabalhar com métodos de ação complexos em seus controladores de componentes do Visualforce ou do Lightning – Algum dos seus códigos lida com algo mais do que o tratamento de informações de e para o usuário? Com os componentes do Visualforce e do Lightning, você pode dividir seu código por meio do modelo-visão-controlador (MVC), uma forma de SOC para o desenvolvimento do cliente. Contudo, usar controladores para todos os seus códigos não garante que você está seguindo a SOC de acordo com sua lógica de negócios.
- Como facilitar a orientação dos novos desenvolvedores em sua base de código – Quanto tempo um desenvolvedor precisa para aprender onde colocar código novo e encontrar o comportamento existente?
Dependendo de onde você escreveu seu código, você já deve estar preparado para lidar com alguns dos cenários acima. Caso não esteja, ou se apenas está curioso, as próximas unidades vão esclarecer o assunto. A tabela a seguir também pode ajudar você a decidir se deve usar esses padrões com base na dimensão e escopo da solução que você está criando.
| Dimensão base da solução ou código | Quantidade de desenvolvedores | Escopo dos requisitos | Quantidade de tipos de clientes e interações | Adequado à SOC? |
|---|---|---|---|---|
| Pequeno | 1 a 2 |
|
|
Geralmente não |
| Pequena a média | 1 a 6 |
|
|
Vale a pena considerar |
| Grande | > 6 |
|
|
Benefícios definitivos |
