Falaaaaaaaaa desenvolvedor, tudo bem??? Estou ótimo, obrigado por perguntar, aliás estou muito ansioso pois hoje darei início a uma série de artigos nas quais eu estarei abordando Arquitetura de Software e Padrões de Projeto de forma simples e objetiva, vou demonstrar em exemplos práticos o que significa esses tais “Patterns” que todo bom desenvolvedor sempre fala.

Já adianto que, vou tentar trazer um padrão de projeto por semana começando pelos mais simples e de fácil entendimento depois partindo para os padrões maiores e mais complexos, assim a curva de aprendizado fica bem mais tranquila.

…

Arquiteto ou Engenheiro?

Antes de falar sobre arquitetura de software e os padrões de projetos propriamente ditos, preciso deixar bem claro a diferença entre Engenheiro de Software e Arquiteto de Software e para isso eu vou usar uma analogia bem simples do dia-a-dia.

Vamos lá, vamos imaginar qual a função de um engenheiro, de forma bem resumida, ele tecnicamente constrói o protótipo de algum produto (seja um imóvel ou uma máquina, não importa), calcula as medidas, aplica as melhores práticas da engenharia para o produto, segue as normas e regras da construção de algo, enfim, um engenheiro trabalha em cima de algo exato, regras, normas cálculos afim de construir algo.

Agora vamos imaginar a função de um arquiteto, também de forma bem resumida, ele planeja e desenha o produto na qual será construído, prezam por algo que seja bonito aos olhos e ao mesmo tempo prático e funcional, é ele quem da toda a base da construção do produto.

Ta bom Lucas, mas ainda não entendi onde isso se encaixa na tecnologia…

Ora jovem leitor, não está obvio? Um Engenheiro de Software enxerga o desenvolvimento como algo exato (ou quase), se tem que aplicar uma funcionalidade ele simplesmente faz essa funcionalidade e aplica em cima de uma arquitetura já definida.

E o arquiteto? Bom o arquiteto enxerga o software com outros olhos, ele, juntamente com o time que definem qual a estratégia que será adota para solucionar o problema, ele constrói e/ou define toda a base que os engenheiros irão programar.

Exemplo de projeto de Arquitetura

https://www.suaobra.com.br/img/not/B5oPtxaEjd.jpeg

Exemplo de projeto de engenharia

https://1.bp.blogspot.com/-nxTKiBWGR2A/Tk728HEIA6I/AAAAAAAAAHg/CVMN-gkaUqY/s1600/2+pav+1.png

Por fim entenda que, um engenheiro de software é apenas um programador comum (Júnior, Pleno, Sênior) e um arquiteto de software também é um programador PORÉM, com uma ampla visão e experiência em desenvolvimento e principalmente no core business do software que ele estará projetando, ou seja, ele é “um nível a mais” que o desenvolvedor sênior.

Quando alguma empresa inicia o desenvolvimento de algum software que será de grande porte, os arquitetos estudam a melhor arquitetura para aquele modelo de negócio, caso tenha uma arquitetura bem definida, com toda certeza, eu te afirmo, a cada nova funcionalidade, ficará mais fácil tanto de realizar manutenção quanto de entender o código. Pelo contrário, uma arquitetura mal definida pode ocasionar problemas gigantescos, como dificuldade de manutenção, dificuldade de crescimento e etc.

Agora que você já entendeu um pouquinho do papel desses 2 caras, eu vou falar sobre aqueles 4 carecas do wallpaper hehe.

…

GoF e os Padrões de projeto

https://takeji-soft.up.n.seesaa.net/takeji-soft/image/GOF-OOPLSA-94-Color-75.jpg?d=a0

 Meu Deus o que é esse tal GoF que você tanto fala???

Calma, pega seu cafézinho que eu tenho uma história bacana sobre esses 4 caras ai da foto.

Vamo lá, GoF significa Gang Of Four (ou Gangue dos Quatro), esses caras ai são os autores de um livro chamado:

Design Patterns Elements of Reusable Object-Oriented Software

Esse livro é uma obra (que eu chamo carinhosamente de bíblia do arquiteto), escrita em 1995 que da início a documentação de 23 padrões de construção de software, atualmente existem mais de 100 padrões já documentados, mas esses 23 são os principais e mais utilizados.

Esses padrões já foram aplicados e testados em projetos reais, os quais, na maioria dos casos deram muito certo, por isso foram documentados e agrupados nessa obra escrita por:

1 — Erich Gamma

2 — Richard Helm

3 — Ralph Johnson

4 — John Vlissides

E eles dividiram esses padrões de projetos em 3 “classes” podemos assim dizer, são elas:

Padrões Criacionais

Os padrões criacionais trabalham em cima da criação de objetos, em grandes projetos pode haver uma grande quantidade de instâncias de objetos e se isso não for controlado, o projeto pode ficar confuso e complexo.

São eles:

• Abstract Factory
• Factory Method
• Builder
• Prototype
• Singleton

Padrões Estruturais

Padrões estruturais como o próprio nome já diz, atuam na parte da estrutura do software, se preocupa em organizar da melhor forma possível as estruturas das classes e objetos.

São eles:

• Adapter
• Composite
• Bridge
• Decorator
• Flyweight
• Facade (se diz façade)
• Proxy

Padrões Comportamentais

Esses padrões definem como um objeto ou classe devem se comportar e com quem devem se relacionar dentro de um software.

• Chain of Responsability
• Iterator
• State
• Command
• Mediator
• Strategy
• Interpreter
• Memento
• Template Method
• Observer
• Visitor

Cada um desses padrões é aplicado em algum cenário, um cenário pode ter um ou mais patterns.

Ta Lucas, mas qual a VANTAGEM DE SE UTILIZAR ESSES PADRÕES DE PROJETOS?

Eu te digo jovem leitor, grande vantagem de se utilizar esses padrões de projetos é ter uma direção de como poder construir um BOM software, como eu já disse esses padrões já foram testados em grandes e diferentes cenários e deram certo, então comece a utilizar.

Outra grande vantagem é que, você consegue fazer toda a sua aplicação seguir o mesmo padrão, então a manutenção do código fica muito mais simples e muito mais viável.

E uma vantagem muito bacana é que, você consegue ver a aplicação funcionando por outro ângulo e modéstia a parte, muito melhor do que sem um padrão de projeto.

Eu sei que agora vocês devem estar “Preciso me tornar arquiteto HOJE”, mas calma, um arquiteto requer anos de experiência trabalhando em diversos tipos de cenários e é uma grande responsabilidade, afinal, é graças a sua arquitetura que o sistema pode crescer, ou não.

…

Conclusão

Bom no artigo de hoje eu falei um pouco sobre arquitetura de software e padrões de projetos, um pouco sobre quem foi que iniciou todo esse movimento, espero que tenham entendido a importância de se utilizar os padrões de projetos nos seus softwares.

Bom galerinha é isso, vou ficando por aqui, bons estudos!!!!

Caso precise entrar em contato, me mande uma mensagem aqui.