Padrões de Projeto: parte 2 de 3

Saudações, concurseiros !

Continuando a nossa série de encontros sobre Padrões de Projeto, hoje vamos falar sobre os padrões Estruturais.

Antes, gostaria de agradecer a todos que apóiam o blog, seja publicando artigos, tirando dúvidas, comprando materiais, enfim, tudo isso que ajuda a nossa comunidade a crescer e ajudar aqueles que estão nesta dura caminhada rumo à aprovação.

Voltando ao nosso artigo, uma pergunta que muitas pessoas me fazem é sobre “qual é a bibliografia que devo utilizar para estudar Padrões de Projeto?”. Bem, há algums opções, como apostilas, materiais on-line, e, até mesmo, aulas presenciais. Disto isto, eu sou um forte defensor do estudo pelos livros consagrados, isto é, por aquela bibliografia que, embora às vezes extensa, contém todas as informações que precisamos para dominar um assunto, de forma aprofundada.

No nosso caso, este livro é o “Design Patterns, Elements of Reusable Object-Oriented Software”, dos autores Erich Gamma, Richard Helm, Ralpho Johnson e John Vlissides, conhecidos como “a gangue dos quatro (Gang of Four)”. É o livro que, basicamente, começou toda esta história de Padrões de Projeto e de onde grande parte das questões de concursos derivam. A leitura não é das mais fáceis, mas tudo o que você precisar saber sobre o assunto estará lá.

Bem, mas o que são os padrões Estruturais?

De acordo com o GoF eles “estão preocupados com a forma com a qual classes e objetos são compostos para formarem estruturas maiores“. Ou seja, são os padrões que nos ajudam a estruturar a arquitetura do software visando a tornar os elementos independentes e facilmente interoperáveis.

Assim, estes são os principais (porém não os únicos) padrões Estruturais :

Adapter

· Converte a interface de uma classe em outra interface que o cliente espera. Adapter permite que classes que normalmente não poderiam trabalhar juntas, devido à incompatibilidade de interfaces, possam fazê-lo.

· Use o Adapter quando:

o Você quer usar uma classe existente, e sua interface não é adequada àquela que você precisa.

o Você quer criar uma classe reusável que coopera com classes não-relacionadas ou não-previstas, isto é, classes que não necessariamente têm interfaces compatíveis.

o Você precisa usar várias subclasses existentes, mas é impraticável adaptar suas interfaces especializando cada uma. Um object adapter pode adaptar a interface de suas classes pais.

gof011

Bridge

•    Desacopla uma interface de sua implementação, de forma que ela possa variar independentemente

•    Use o Bridge quando:

o    Você quer evitar um vínculo entre a abstração e a implementação. Esse pode ser o caso, por exemplo, quando a implementação deve ser selecionada em tempo de execução.
o    Ambas a abstração e a implementação devem ser estensíveis através de subclasses.
o    Mudanças na implementação de uma abstração não deveriam ter impacto sobre os clientes, isto é, seu código não deveria ser recompilado.

gof02

Mas o que é este “acoplamento” que o Bridge tenta evitar? Podemos aprender mais sobre isto dando uma olhada em uma das questões comentadas por mim na prova do TJ-PA da FCC (disponível em breve na loja). Acoplamento e coesão são dois princípios básicos da Engenharia de Software que têm íntima relação. Observe:

36 – Considere as afirmativas abaixo.

I. A mais adequada coesão entre tarefas de um módulo é a sequencial.

II. É mais adequado o acoplamento por controle entre módulos do que nenhum acoplamento direto.

III. O baixo acoplamento entre módulos resulta em menor propensão a efeitos de propagação.

De acordo com as recomendações da Engenharia de Software quanto à melhoria da qualidade dos projetos, é correto o que se afirma APENAS em

(A) III.

(B) II e III.

(C) I.

(D) II.

(E) I e II.

Acoplamento e coesão são conceitos fundamentais da Engenharia de Software. O livro do Pressman apresenta-os de forma clara e sucinta. Vamos revisá-los.

Coesão: é a medida da “força funcional” relativa de um módulo. Um módulo coeso realiza uma única tarefa dentro de um procedimento de software, requerendo pouca ou nenhuma interação
com procedimentos sendo realizados em outras partes de um programa. O ideal é buscar uma alta coesão.

Há vários tipos de coesão, alguns menos desejáveis do que outros.

Tipos indesejáveis de coesão:

Coesão coincidental: ocorre quando um módulo realiza um conjunto de tarefas frouxamente relacionadas.

Coesão lógica: ocorre quando um módulo realiza um conjunto de tarefas que estão relacionadas logicamente.

Coesão temporal: ocorre quando um módulo realiza um conjunto de tarefas que devem ser executadas dentro do mesmo decurso de tempo.

Tipos intermediários de coesão:

Coesão procedural: ocorre quando os elementos de processamento do módulo são relacionados e devem ocorrer em uma ordem específica.

Coesão de comunicação: ocorre quando todos os elementos de processamento do módulo se concentram em uma única área de uma estrutura de dados.

Coesão desejável

Coesão funcional: quando um módulo realiza uma única tarefa procedural distinta.

Acoplamento: é a medida de interconexão entre módulos em uma estrutura de software. Depende da complexidade de interface entre eles, o ponto no qual a entrada ou referência é feita a um módulo e que dados passam pela interface. O ideal é buscar o mais baixo acoplamento.

Também, assim como Coesão, há vários tipos de Acomplamento, em diferentes níveis.

Tipos indesejáveis de Acoplamento:

Acoplamento comum: quando um conjunto de módulos acessa uma área global de dados

Acoplamento por conteúdo: ocorre quando um módulo faz uso de estruturas de dados ou de controle mantidas no escopo de outro módulo

Tipo intermediário de Acoplamento:

Acoplamento por controle: quando módulo passa decisões de controle a outro módulo

Tipo desejável de acoplamento:

Acomplamento de dados: ocorre quando apenas uma lista de dados simples é passada como parâmetro de um módulo para o outro, com uma correspondência um-para-um de itens.

Voltando à questão, a assertiva I está errada, pois a coesão mais adequada é a funcional. A assertiva II está errada, pois o ideal é ter nenhum acoplamento.

Resposta: Letra A

Referência:

Pressman, Roger S. Software Engineering: A Practiotioner’s Approach. Editora: McGraw-Hill.
Ano: 2001. Edição: 5 http://www.submarino.com.br/produto/1/1348168?franq=271796

Continuando com nossos padrões.

Composite

• Compõe objetos em estruturas de árvore para representar hierarquias parte-todo. Composite deixa os clientes tratar objetos individuais e composições de objetos livremente

• Use Composite quando:

o Você quer representar hierarquias parte-todo de objetos
o Você quer que os clientes possam ignorar a diferença entre composições de objetos e objetos individuais. Clientes vão tratar os objetos na estrutura composta de forma uniforme

gof03

Decorator

• Anexa responsabilidades adicionais a um objeto dinamicamente. Decoradores fornecem uma alternativa flexível em relação à herança, para estender funcionalidades

• Use o Decorator:

o Para adicionar responsabilidades a objetos individuais dinâmica e transparentemente, isto é, sem afetar os outros objetos
o Para responsabilidades que podem ser retiradas
o Quando a extensão por subclasses é impraticável. Algumas vezes uma grande quantidade de combinações de de subclasses é possível, causando uma explosão na hierarquia

gof04

Proxy

• Fornece um objeto representante ou um marcador de outro objeto para controlar o acesso ao mesmo

• Proxy é aplicável toda vez que há uma necessidade de uma referência mais versátil ou sofisticada do que um simples ponteiro para um objeto

• Alguns tipos de proxy:

o Remote proxy
o Virtual proxy
o Protection poxy
o Smart reference

gof05

Bons estudos!

Nando Pedrosa

Obras do Autor:
Prova Comentada:  TRT 2 Região (São Paulo)

»crosslinked«

nandopedrosa

Analista de Finanças e Controle - Ministério da Fazenda/Coordenação de Sistemas Graduação: Universidade Federal de Pernambuco Certificações: ITIL Foundation Certified Java Programmer Certified Java Associate Certified Aprovações: Concurso Ano Cargo Posição Organizadora PBGÁS 2007 Analista de Sistemas 1 FCC SERPRO 2008 Administração de TI 1 CESPE COPERGÁS 2008 Analista de Sistemas 1 UPENET INMETRO 2007 Analista de Sistemas 2 CESPE STN 2008 AFC-TI 2 ESAF STJ 2008 Analista Judiciário 3 CESPE TRF-5 2008 Analista Judiciário 5 FCC TRF-5 2008 Técnico Judiciário 5 FCC TCU 2008 ACE-TI 7 CESPE TJ-PE 2007 Analista Judiciário 11 FCC BNDES 2008 Analista de Sistemas 27 CESGRANRIO

Você pode gostar...

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *