Principios SOLID em Imagens

A maioria dos desenvolvedores utilizam a POO - Programação Orientada à Objeto e devem ter ouvido falar sobre SOLID, essa sigla é acrônimo para (iniciais do nome em inglês) para os principios para construção de software com qualidade e manutentabilidade. 

Para facilitar a compreensão desses conceitos, foi criado as imagens abaixo, afinal de contas nada melhor que desenhar para se fazer entender.

Princípio da responsabilidade única - (Single-responsibility principle)

Uma classe, microsserviços, componentes devem ser responsável por apenas uma atividade. Utilizando esse principio você poderá garantir que qualquer alteração que venha a acontecer no código irá impactar somente seus dependentes diretos. 

Princípio aberto-fechado (Open–closed principle)

As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto  fechado para modificação. Utilizando esse principio podemos garantir que as alterações sendo realizadas através de extensão da entidade base nada será afetado no contexto dos códigos que utilizam a classe original. 

Princípio da substituição de Liskov (Liskov substitution principle)

O objetivo desse princípio é verificar que uma subclasse poderá ser substituída pela sua classe base sem erros. O principio é uma homenagem a Barbara Liskov, ela definiu que "se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa".

Princípio de segregação de Interface (Interface segregation principle)

Crie interfaces refinadas e específicas, porque elas são melhores que interfaces genéricas. Não devemos ser forçados a depender das interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da implementação de grandes interfaces únicas.

Princípio da inversão de dependência (Dependency inversion principle)

Chega um momento no desenvolvimento de software em que nosso aplicativo será amplamente composto por módulos. Quando isso acontece, precisamos esclarecer as coisas usando a injeção de dependência. De uma forma objetiva o princípio nos faz entender que sempre devemos depender de abstrações e não das implementações.

Todos os desenvolvedores devem seguir esses cinco princípios, porque eles irão garantir um código mais limpo, eficiente e mais fácil de ser testado.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

As imagens são traduções das orignais do artigo de Ugonna Thelma em https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

Enviando o Resultado de uma Consulta SQL em formato HTML via Logic App

É um requisito bem simples, você precisa que um resultado de consulta ao banco de dados, ou seja, uma saída direta de uma tabela ou um resultado retornado de procedimento precisa ser enviado por email. Esse e-mail pode ser um retrato do momento da execução, algumas verificação diária de um processamento ou simplesmente uma notificação de algo que não deveria ter acontecido. E para facilitar o entendimento enviaremos o resultado formatado em HTML.

Existem inúmeras maneiras mais ou menos eficazes de realizar essa atividade, essa é uma forma de exemplificar um processo simples e rápido de ser implementado.

Consulta SQL

Suponhamos que precisamos enviar uma listagem dos produtos mais vendidos nos últimos sete dias e para isso criamos a consulta abaixo:

Abaixo fazemos pequenas adaptações na consulta, para formatar o resultado para que seja enviado por email e tenha um visual mais legível.

1. Aplicamos a tag <li> a tag para listar todos os registros de conjunto de dados

2. Em seguida, envolvemos a lista de itens com a tag HTML <ul>.

O resultado da consulta não é visualmente bonito, já o resultado em HTML :-)

Azure Logic App

Agora vamos criar o nosso Logic App com um gatilho recorrência, a execução da consulta e uma ação "Enviar um e-mail"

Gatilho

Vamos programar para que o aplicativo execute diariamente às 20h.

Ação

Para facilitar vamos executar diretamente o comando SQL, entretanto poderíamos optar por executar um procedimento. Importante configurar o método de autenticação.

Resultado

Agora basta selecionarmos a plataforma que irá efetuar o disparo do email, neste caso está configurado o disparo por uma conta do Gmail. Além da possibilidade de adicionar texto extra ao corpo do email, podemos ainda utilizar fórmulas para coletar outras informações.

Importante, como o resultado de uma consulta pode ser mais de uma linha, essa ação criará um laço que será executado para cada linha, entretanto nossa consulta sempre irá retornar somente uma linha, logo somente um email será disparado.

Execução 

Após a execução podemos verificar se as etapas foram concluídas com êxito e tempo de execução.

Checando o Email

E podemos ver o e-mail que será entregue todo dia, uma forma simples para atingir um objetivo. 

Até a próxima! :-)

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Diferença entre Arquitetura e Design de Software

Muitos desenvolvedores normalmente acabam misturando os elementos entre arquitetura e design. Vou tentar exemplificar as diferenças entre design de software e arquitetura de software e tentarei mostrar a importância para um desenvolvedor conhecer um pouco sobre arquitetura de software e muito design de software.

Definição de arquitetura de software

Arquitetura de software é o processo de conversão de características de software como flexibilidade, escalabilidade, viabilidade, reutilização e segurança em uma solução estruturada que atenda às expectativas técnicas e de negócios. Segue alguns exemplos de padrão de arquitetura utilizados atualmente no mercado.

Arquitetura sem servidor

Arquitetura sem servidor é normalmente dividida em duas categorias principais. O primeiro é "Back-end como serviço (BaaS)" e o segundo é "Funções como serviço (FaaS)". A arquitetura sem servidor ajudará você a economizar muito tempo cuidando e corrigindo erros de tarefas regulares de implantação e servidores.

Arquitetura orientada a eventos

A idéia principal é desacoplar as partes do sistema e cada parte será acionada quando um evento interessante de outra parte for acionado. A característica mais importante neste padrão é gerador do evento não conheço quais são os ouvintes que estão ouvindo seu evento,  a idéia principal é dissociar as partes do sistema.

Arquitetura de microsserviços

A arquitetura de microsserviços se tornou a arquitetura mais popular nos últimos anos. Depende do desenvolvimento de serviços modulares pequenos e independentes, nos quais cada serviço resolve um problema específico ou executa uma tarefa exclusiva e esses módulos se comunicam por meio de uma API bem definida para atender à meta de negócios. 

Definição de design de software

O design do software é responsável pelo design do nível de código, como o que cada módulo está fazendo, o escopo das classes e os objetivos das funções, etc. Para um desenvolvedor é importante saber qual é o princípio do SOLID (mais informações em https://www.marcelogoberto.com.br/2020/04/principios-do-solid-que-todo.html) e como um padrão de design deve resolver problemas regulares. Aqui também temos alguns exemplos de padrões de design.

Factory Pattern

É o padrão de design mais usado no mundo OOP, permite às classes delegar para subclasses decidirem, isso é feito através da criação de objetos que chamam o método fábrica especificado numa interface e implementado por um classe filha ou implementado numa classe abstrata e opcionalmente sobrescrito por classes derivadas 

Design Patterns

O padrão é bem simples, vamos pensar o que acontece na vida real... Utilizamos nas nossas construções civis um padrão de tomadas e plugues, um belo dia saiu o padrão brasileiro de tomadas e plugues, quando você compra um aparelho que atende a essa norma logo pensa, vou ter que comprar um adaptador para adaptar esse plugue a tomada que está em casa, pois são padrões (modelos) diferentes.

Conclusão

Uma simples analogia exemplifica muito bem a principal diferença entre arquitetura e design de software, sendo a solução um corpo humano, a arquitetura é responsável pela composição corpórea (esqueleto, disposição do órgãos, vasos sanguíneos) e o design de software será responsável por garantir funcionamento de cada órgão. Em linguagem técnica, arquitetura é alto nível e design é nível de código.

Os arquitetos de software devem ter um bom conhecimento sobre as soluções existentes que os ajudam a tomar decisões corretas na fase de planejamento e um desenvolvedor de software deve saber mais sobre design de software e bastante sobre arquitetura de software para facilitar a comunicação interna dentro da equipe.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br