Artigo Acadêmico: Padrões de Projeto de Software - Criacional, Comportamental e Estrutural

ARTIGO VALOR 30 NA MÉDIA TEMAS PADRÃO CRIACIONAL PADRÃO COMPORTAMENTAL PADRÃO ESTRUTURAL SOFTWARE GRUPO DE 3 ALUNOS NORMAS ABNT ENTREGA 24102022 RESPONDER O QUE É CADA PADRÃO QUAL A UTILIDADE DE CADA PADRÃO INTERLIGAÇÕES E DIFERENÇA DOS PADRÕES Estudo sobre padrões de software criacional comportamental e estrutural Alan Felipe1 Miguel Broca2 Valterlande3 1Instituto de Informática Universidade da Amazônia UNAMA Caixa Postal 76821063 Porto Velho RO Brazil 2Department of Computer Engineering University of AmazôniaDurham Porto Velho Brazil felipemeloalan valterlandemacedo321gmailcom miguelaugustoenghotmailcom Abstract This article aims to explain some of the main software development standards today The patterns presented in this work are creational behavioral and structural During the development of the article the concepts of each mentioned software standard their applications and the differences between the standards will be presented At the end of the articles development it will be possible to have a clear view of these three patterns as the most appropriate pattern to meet the software development situation Resumo Este artigo tem por objetivo realizar uma explanação sobre alguns dos principais padrões de desenvolvimento de software utilizados atualmente Os padrões apresentados neste trabalho são criacional comportamental e estrutural Durante o desenvolvimento do artigo serão apresentados conceitos de cada padrão de software citado suas aplicações e as diferenças entre os padrões Ao final do desenvolvimento do artigo será possível ter uma visão clara sobre esses três padrões assim como o padrão mais adequado para atender determinada situação no desenvolvimento do software 1 Introdução Os padrões de projeto de software são de grande importância para o desenvolvimento de programas que trabalham com orientação à objetos No entanto a ideia de projetar soluções de software a partir de um estudo já conhecido não teve origem no estudo de software em si mas sim a partir de um documento publicado em 1977 pelo arquiteto Christopher Alexander que apresentava uma relação de 255 padrões de arquitetura civil que apresentavam questões comuns da arquitetura descrevendo tanto o problema quanto as justificativas para a sua solução Christopher elaborou uma forma de discernir similaridades entre grandes projetos com alto nível de qualidade ao qual chamou de padrões Com o passar dos anos o estudo sobre padrões desenvolvido por Christopher Alexander foi notado pelas comunidades acadêmicas e profissionais de desenvolvimento de software onde foi adaptado para o mundo da engenharia de software por Erich Gama Richard Helm Ralph Johnson John Vlissides responsáveis pela criação do livro Padrões de Projeto Soluções reutilizáveis de software orientado a objetos considerado como uma leitura fundamental para profissionais e estudantes de desenvolvimento de software O livro citado apresenta de forma detalhada 23 padrões de projeto que são divididos em três categorias criacional comportamental e estrutural Durante o desenvolvimento do artigo serão apresentados os padrões que compõem cada uma das três categorias seu contexto aplicação e possíveis resultados da utilização de cada padrão de projeto de software 2 Definição de padrão de projeto de software A definição de padrão de projeto de software não é tão objetiva apesar de sua ampla utilização por desenvolvedores de software Cada padrão de software é considerado uma regra definida em três partes contexto problema e solução Logo é possível definir de forma resumida padrão de projeto de software como como a solução recorrente para um problema em um contexto mesmo que em projetos e áreas distintas No entanto é importante ressaltar que se existir uma solução para um determinado contexto ela não será necessariamente constituída como um padrão pois é necessário que ela possua uma característica fundamental poder ser utilizada repetidamente 3 Características de um padrão de projeto Para que um determinado padrão de projeto possa ser devidamente utilizado para o desenvolvimento de softwares orientados à objetos é necessário que ele possua algumas características específicas 31 Relatar o problema apresentado É necessário que o padrão relate de maneira clara a qual problema ele será aplicado e caso necessário se existirá alguma condição a ser préestabelecida 32 Apresentar uma solução O padrão de projeto deve apresentar uma solução completa que além de funcionar para um problema específico pode ser aplicada de maneiras diferentes 33 Nome do padrão de projeto O nome escolhido para o padrão de projeto é de fundamental importância para o seu entendimento pois descreverá o problema as soluções e consequências Podese utilizar como exemplo de nome o padrão Factory Method que pelo próprio nome já dá ao desenvolvedor uma ideia de que esse método atuará como uma espécie de fábrica de funcionalidades dentro da programação orientada à objetos 4 A escolha do padrão de projeto de software Existem diversos padrões de projeto de software disponíveis para o uso do desenvolvedor No entanto uma das tarefas mais árduas é identificar dentro todos os padrões o que será a melhor escolha para o problema apresentado Entretanto existem alguns critérios que podem auxiliar o profissional de desenvolvimento a escolher o melhor padrão de projeto É necessário realizar um processo de análise da intenção do padrão a ser utilizado ou seja qual o objetivo do padrão e a sua forma de solução Realizar um estudo comparativo entre padrões com características semelhantes com o intuito de selecionar o padrão mais adequado ao problema proposto Verificar como padrões diferentes podem se relacionar para a solução do problema Considerar o que pode ser variável no projeto analisando o que pode ser alterado para reaproveitálo 5 Padrões de projeto criacionais Os padrões criacionais adiam o processo de criação dos objetos no desenvolvimento do software ajudando a gerar um sistema independentemente de como seus objetos são criados compostos e representados Um padrão criacional de classe usa a herança para variar a classe que é instanciada enquanto um padrão criacional referente a um objeto delegará a instanciação para outro objeto Os padrões de criação tornamse importantes à medida que os sistemas evoluem no sentido de dependerem mais da composição de objetos do que a herança de classes O desenvolvimento baseado na composição de objetos possibilita que eles sejam compostos sem a necessidade de mostrar o seu interior como acontece na herança de classe o que possibilita a definição do comportamento dinâmico e a ênfase deslocase da codificação de maneira rígida de um conjunto fixo de comportamentos para a definição de um conjunto menor de comportamentos que podem ser compostos em qualquer número para definir comportamentos mais complexos Consequentemente os padrões de criação dão muita flexibilidade no que é criado quem cria como e quando é criado Eles possibilitam configurar um software com objetos produto que variam amplamente em estrutura e funcionalidade A configuração pode ser dinâmica ou estática Neste artigo serão apresentados alguns dos principais padrões de projeto relacionados ao gênero criacional 51 Factory Method O entendimento acerca do padrão factory method pode ser ilustrado através da seguinte situaçãoproblema Um aplicativo de gerenciamento de logística foi desenvolvido para parta uma determinada empresa A versão inicial do aplicativo só disponibiliza transporte com caminhões portanto a maior parte código fica dentro da classe Truck Depois de um tempo a empresa cresce e com isso novos meios de transporte devem ser implementados na aplicação Nessa situação a maior parte do seu código é acoplada à classe Truck A adição Ship ao aplicativo exigiria alterações em toda a base de código Além disso se mais tarde fosse necessário adicionar outro tipo de transporte ao aplicativo provavelmente seria necessário fazer todas essas alterações novamente O resultado desse processo seria um código bastante acoplado repleto de condicionais que alteram o comportamento do aplicativo dependendo da classe de objetos de transporte Factory Method é um padrão de projeto criacional que disponibiliza uma interface para criar objetos em uma superclasse mas permite que as subclasses alterem o tipo de objeto que será criado no desenvolvimento do software 52 Singleton O Padrão Singleton tem como objetivo garantir que uma classe tenha apenas uma instância de si mesma e que disponibilize um ponto global de acesso a ela Logo uma classe gerencia a própria instância dela além de evitar que qualquer outra classe crie uma instância dela Para criar a instancia é necessário passar pela classe obrigatoriamente nenhuma outra classe pode instanciar ela O Padrão Singleton também oferece um ponto global de acesso a sua instância A própria classe sempre vai oferecer a própria instância dela e caso não tenha ainda uma instância então ela mesma cria e retorna essa nova instância criada Em suma o padrão singleton resolve dois problemas importantes na estrutura do projeto de software primeiramente ele garante que uma classe tenha apenas uma única instância Além disso o padrão singleton fornece um ponto de acesso global para aquela instância É possivel a partir da definição do padrão singleton realizer uma comparação com o padrão façade uma classe facade pode frequentemente ser transformada em uma singleton já que um único objeto facadea é suficiente na maioria dos casos Uma analogia clara sobre o padrão singleton é o governo Por exemplo Um país pode ter apenas um governo oficial Independentemente das identidades pessoais dos indivíduos que formam governos o título O Governo de X é um ponto de acesso global que identifica o grupo de pessoas no command 6 Padrões de projeto estruturais Os padrões de categoria estrutural preocupamse em organizar a estrutura das classes e os relacionamentos entre classes e objetos da forma mais adequada visando formar estruturas maiores A flexibilidade obtida pela composição de objetos provém da capacidade de mudar a composição em tempo de execução o que não é possível com a composição estática herança de classes Abaixo são conceituados alguns padrões de projeto estruturais 61 Adapter O padrão adapter permite que objetos com interfaces incompatíveis colaborarem entre si O adaptador é um objeto especial que converte a interface de um objeto para que outro objeto possa entendêlo Um adaptador encobre um dos objetos para esconder a complexidade da conversão acontecendo nos bastidores O objeto encobrido não fica ciente do adaptador Por exemplo é possivel encobrir um objeto que opera em metros e quilômetros com um adaptador que converte todos os dados para unidades imperiais tais como pés e milhas Adaptadores podem não só converter dados em vários formatos mas também podem ajudar objetos com diferentes interfaces a colaborarREFACTORING2014 A estrutura do padrão Adapter é apresentada na figura abaixo Figure 1 Estrutura do padrão Adapter É póssivel definir uma relação do Adapter com o padrão decorator por exemplo O Adapter muda a interface de um objeto existente enquanto que o Decorator melhora um objeto sem mudar sua interface Além disso o Decorator suporta composição recursiva o que não seria possível quando você usa o Adapter 62 Decorator O Decorator é um padrão de projeto estrutural que permite que sejam acoplados novos comportamentos para objetos ao colocálos dentro de invólucros de objetos que contém os comportamentos Abaixo é possivel identificar a estrutura base utilizada no padrão decorator Figure 2 Estrutura do padrão Decorator 621 O Componente declara a interface comum tanto para os envoltórios como para os objetos envolvidos 622 O Componente Concreto é uma classe de objetos sendo envolvidos Ela define o comportamento básico que pode ser alterado por decoradores 623 A classe Decorador Base tem um campo para referenciar um objeto envolvido O tipo do campo deve ser declarado assim como a interface do componente para que possa conter ambos os componentes concretos e os decoradores O decorador base delega todas as operações para o objeto envolvido 624 Os decoradores concretos sobrescrevem métodos do decorador base e executam seus comportamentos tanto antes como depois de chamarem o método pai 625 O Cliente pode envolver componentes em múltiplas camadas de decoradors desde que trabalhe com todos os objetos através da interface do componente É possivel estabelecer uma pequena relação entre os padrões Decorator e Strategy o Decorator pode ser relacionado ao padrão de projeto Strategy pois permite mudança da superficie de um objeto enquanto o Strategy permite que você mude suas estruturas internas 63 Facade O Facade é um padrão de projeto de gênero estrutural que fornece uma interface simplificada para uma biblioteca um framework ou qualquer conjunto complexo de classes dentro da aplicação Abaixo é possivel verificar a estrutura básica do padrão Façade Figure 3 Estrutura do padrão Facade 631 A Fachada disponibiliza um acesso conveniente para uma pequena parte da funcionalidade do subsistema Ela sabe onde direcionar o pedido do cliente e como operar todas as partes móveis 632 Uma classe Fachada Adicional pode ser criada para prevenir a poluição de uma única fachada com funcionalidades não relevantes que podem tornálo mais uma estrutura complexa Fachadas adicionais podem ser usadas tanto por clientes como por outras fachadas 633 O Subsistema Complexo consiste em dúzias de objetos variados trabalhando simultaneamente 634 As classes do subsistema não estão cientes da existência da fachada Elas operam dentro do sistema e trabalham entre si diretamente O Cliente usa a fachada ao invés de chamar os objetos do subsistema diretamente Existe uma relação entre os padrões de projeto façade e adapter o Facade define uma nova interface para objetos que já existem enquanto que o Adapter tenta fazer uma interface já existente ser utilizável O Adapter geralmente envolve apenas um objeto enquanto que o Facade trabalha com um inteiro subsistema de objetos 7 Padrões de projeto comportamentais Os padrões de projeto comportamentais são direcionados aos algoritmos e a designação de responsabilidades entre objetos Existem diversos padrões de projeto do gênero comportamental No entanto para o desenvolvimento deste artigo são apresentados os padrões abaixo 71 Iterator Iterator é um padrão de projeto comportamental que permite que elementos sejam percorridos de uma coleção sem expor suas representações como listas e pilhas por exemplo Figure 4 Estrutura do padrão Iterator 711 A interface Iterador declara as operações necessárias para percorrer uma coleção buscar o próximo elemento pegar a posição atual recomeçar a iteração etc 712 Iteradores Concretos implementam algoritmos específicos para percorrer uma coleção O objeto iterador deve monitorar o progresso da travessia por conta própria Isso permite que diversos iteradores percorram a mesma coleção independentemente de cada um 713 A interface Coleção declara um ou mais métodos para obter os iteradores compatíveis com a coleção Observe que o tipo do retorno dos métodos deve ser declarado como a interface do iterador para que as coleções concretas possam retornar vários tipos de iteradores 714 Coleções Concretas retornam novas instâncias de uma classe iterador concreta em particular cada vez que o cliente pede por uma Você pode estar se perguntando onde está o resto do código da coleção Não se preocupe ele deve ficar na mesma classe É que esses detalhes não são cruciais para o padrão atual então optamos por omitilos 715 Logo o cliente não fica acoplado a suas classes concretas permitindo usar várias coleções e iteradores com o mesmo código cliente É possível utilizar o padrão Factory Method junto com o Iterator para permitir que uma coleção de subclasses retornem diferentes tipos de iteradores que são compatíveis com as coleções 72 Memento O Memento é um padrão de projeto comportamental que permite ao desenvolvedor salvar e restaurar o estado anterior de um objeto sem revelar os detalhes de sua implementação A estrutura do padrão Memento pode ser analisada conforme a figura abaixo Figure 5 Estrutura do padrão Memento 721 A classe Originator pode produzir retratos de seu próprio estado bem como restaurar seu estado de retratos quando necessário 722 O Memento é um objeto de valor que age como um retrato do estado da originadora 723 A Caretaker sabe não só quando e por quê capturar o estado da originadora mas também quando o estado deve ser restaurado 724 Na implementação apresentada a classe memento está aninhada dentro da originadora Isso permite que a originadora acesse os campos e métodos do memento mesmo que eles tenham sido declarados privados No entanto a cuidadora tem um acesso muito limitado aos campos do memento que permite a ela armazenar os mementos em uma pilha mas não permite alterar seu estado É possível utilizar o padrão Memento junto ao padrão Iterator para capturar o estado de iteração atual e revertêlo caso necessário 73 Observer O Observer é um padrão de projeto comportamental que permite definir um mecanismo de assinatura para notificar múltiplos objetos sobre quaisquer eventos que aconteçam com o objeto que eles estão observando Figure 6 Estrutura do padrão Observer 731 A Publicadora manda eventos de interesse para outros objetos Esses eventos ocorrem quando a publicadora muda seu estado ou executa algum comportamento As publicadoras contêm uma infraestrutura de inscrição que permite novos assinantes se juntar aos atuais assinantes ou deixar a lista 732 Quando um novo evento acontece a publicadora percorre a lista de assinantes e chama o método de notificação declarado na interface do assinante em cada objeto assinante 733 A interface do Assinante declara a interface de notificação Na maioria dos casos ela consiste de um único método atualizar O método pode ter vários parâmetros que permite que a publicadora passe alguns detalhes do evento junto com a atualização 734 Assinantes Concretos realizam algumas ações em resposta às notificações enviadas pela publicadora Todas essas classes devem implementar a mesma interface para que a publicadora não fique acoplada à classes concretas 735 Geralmente assinantes precisam de alguma informação contextual para lidar com a atualização corretamente Por esse motivo as publicadoras quase sempre passam algum dado de contexto como argumentos do método de notificação A publicadora pode passar a si mesmo como um argumento permitindo que o assinante recupere quaisquer dados diretamente 736 O Cliente cria a publicadora e os objetos assinantes separadamente e então registra os assinantes para as atualizações da publicadora Existe uma diferença entre o Mediator e o Observer Na maioria dos casos é possivel implementar qualquer um desses padrões mas em certas situações é preciso aplicar ambos simultaneamente 74 Strategy O padrão de projeto de software Strategy permite que você defina uma família de algoritmos coloqueos em classes separadas e faça os objetos deles intercambiáveis A figura apresentada abaixo ilustra a estrutura do padrão Strategy Figure 7 Estrutura do padrão Strategy 741 O Contexto mantém uma referência para uma das estratégias concretas e se comunica com esse objeto através da interface da estratégia 742 A interface Estratégia é comum à todas as estratégias concretas Ela declara um método que o contexto usa para executar uma estratégia 743 Estratégias Concretas implementam diferentes variações de um algoritmo que o contexto usa 744 O contexto chama o método de execução no objeto estratégia ligado cada vez que ele precisa rodar um algoritmo O contexto não sabe qual tipo de estratégia ele está trabalhando ou como o algoritmo é executado 745 O Cliente cria um objeto estratégia específico e passa ele para o contexto O contexto expõe um setter que permite ao cliente mudar a estratégia associada com contexto durante a execução da aplicação O padrão de projeto Decorator permite que você mudar um objeto de forma superficial enquanto o Strategy permite mudar as estruturas internas do objeto 75 Template Method O Template Method é um padrão de projeto comportamental que define a estrutura básica de um algoritmo na superclasse mas deixa as subclasses sobrescreverem etapas específicas do algoritmo sem modificar sua estrutura interna Figure 8 Estrutura do padrão Template Method 751 A Classe Abstrata declara métodos que agem como etapas de um algoritmo bem como o próprio método padrão que chama esses métodos em uma ordem específica Os passos podem ser declarados como abstratos ou ter alguma implementação padrão 752 As Classes Concretas podem sobrescrever todas as etapas mas não o próprio método padrão O Factory Method é uma forma especializada do Template Method Logo o Factory Method pode servir como uma etapa em um Template Method maior e mais complexo 5 Conclusão O profissional da área de tecnologia da informação e desenvolvimento de software precisa ter conhecimentos de aplicação de padrões de projeto para projetar seu software de maneira clara e eficiente O desenvolvimento deste artigo teve por objetivo apresentar alguns dos padrões de projeto de software mais utilizados no Mercado de desenvolvimento sepárado por gêneros criacional estrutural e comportamental trabalhando as suas definições aplicação estrutura e relação com outros padrões de projeto 7 References Padrões de Projeto disponível em httpsrefactoringguruptbrdesignpatterns FREEMAN E Use a cabeça padrões de projeto Rio de Janeiro Alta Books 2009 GAMMA Erich Padrões de projeto soluções reutilizáveis de software orientado a objetos Porto Alegre Bookman 2005