Os padrões de projeto GoF (Gang of Four) são divididos conforme o escopo em que atuam: padrões de classe e padrões de objeto. Essa classificação ajuda a determinar a natureza das soluções propostas por cada padrão. Vamos analisar os padrões apresentados na questão em relação a seus escopos.

Conceitos de TI:
Os padrões de classe lidam com o relacionamento entre classes e suas subclasses, geralmente utilizando herança, o que significa que seus relacionamentos são estáticos e definidos em tempo de compilação. Já os padrões de objeto focalizam nas interações entre objetos, que podem ser alteradas em tempo de execução, sugerindo um comportamento mais dinâmico. A maioria dos padrões GoF, como mencionado na literatura, atua no escopo de objeto devido à flexibilidade e dinamismo requeridos em sistemas complexos.

Análise das Alternativas:

Alternativa A:
2, 1, 1, 2, 1. Aqui, a sequência mistura escopos de objeto e classe. Vamos analisar os padrões individualmente para concluir se cada padrão corresponde corretamente ao seu escopo.

Alternativa B:
1, 2, 2, 1, 2. A sequência também apresenta uma mistura entre o escopo de classe e objeto. Nosso objetivo é identificar a correta correspondência baseada na análise dos padrões.

Alternativa C:
2, 2, 1, 2, 1. Esta é a alternativa correta conforme a análise dos padrões:
<ul style="margin-bottom: 1.5em;">
 <li>Bridge - escopo de objeto, pois lida com a separação da abstração da implementação, permitindo escolher implementações em tempo de execução.</li>
 <li>Façade - escopo de objeto, pois fornece uma interface simplificada para um conjunto de interfaces em um subsistema.</li>
 <li>Adapter - escopo de classe, pois pode ser estático devido à conversão de uma interface de classe para outra.</li>
 <li>Observer - escopo de objeto, já que lida com uma relação dinâmica um-para-muitos entre objetos.</li>
 <li>Interpreter - escopo de classe, pois se relaciona a gramáticas e o tratamento de expressões linguísticas.</li>
</ul>

Alternativa D:
1, 2, 2, 2, 2. Esta alternativa é incorreta, pois a categorização do Adapter e do Interpreter está erroneamente como escopo de objeto, quando deveriam ser de classe.

Fundamentação Técnica:
Compreender os padrões de projeto é essencial tanto para o desenvolvimento de software quanto para o gerenciamento eficiente de sistemas. O livro "Design Patterns: Elements of Reusable Object-Oriented Software" por Gamma, Helm, Johnson e Vlissides, fornece informações detalhadas sobre cada padrão e seu escopo, ajudando desenvolvedores a aplicar esses conceitos para resolver problemas comuns de design de software.

Gabarito: Letra C

O padrão de projeto Mediator tem como propósito promover o baixo acoplamento entre um conjunto de objetos, definindo um objeto que encapsula a interação entre os objetos desse conjunto de modo a evitar que haja referências diretas entre eles. O padrão de projeto Observer define uma relação de dependência de um ou mais objetos em relação a um determinado objeto x, de forma que quando houver uma mudança no estado de x, todos os objetos dependentes de x sejam notificados e atualizados automaticamente. Já o padrão de projeto Facade tem como propósito definir uma interface unificada e de mais alto nível a um conjunto de interfaces de um subsistema, facilitando o uso desse subsistema. Dessa forma, a relação correta é a apresentada na alternativa (D): 2 – 3 – 1.

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Na discussão sobre padrões de projeto no contexto de programação orientada a objetos, especialmente os padrões GRASP (General Responsibility Assignment Software Patterns), um dos conceitos mais fundamentais é o de low coupling ou baixo acoplamento.
 
 
 Os padrões GRASP são um conjunto de diretrizes destinadas a resolver problemas comuns de atribuição de responsabilidade em projetos de software. O padrão de low coupling é crucial para a criação de sistemas de software escaláveis e manuteníveis.
 

 A proposição em questão relata que a função do low coupling é "garantir que o acoplamento entre classes ou entidades permaneça fraco, de forma a permitir a maior reutilização possível". Isso é consistentemente alinhado com o objetivo geral do padrão low coupling.
 

 O conceito de acoplamento se refere ao grau de dependência direta entre componentes de software, como classes ou módulos. Classes fortemente acopladas têm múltiplas dependências entre si, o que pode levar a sistemas que são difíceis de entender, modificar ou estender. Por outro lado, um baixo acoplamento implica que as classes operam independentemente umas das outras, aumentando assim a modularidade do sistema.
 
 
 O baixo acoplamento facilita a manutenção e a escalabilidade do software, pois alterações em um componente tendem a requerer menos mudanças em outros componentes. Além disso, low coupling aumenta a possibilidade de reutilização de um componente, já que sua independência permite que ele seja usado em diferentes contextos sem adaptação significativa.
 

 Analisando as alternativas da questão:
 
 
 <ul>
 <li>C) Certo: Correto conforme discutido acima, já que a função do padrão de baixo acoplamento é precisamente promover a independência entre as classes, aumentando a reutilização e facilitando a manutenção.</li>
 
 <li>E) Errado: Seria incorreto negar a assertiva pois ela encapsula de maneira fidedigna o propósito do low coupling dentro dos padrões GRASP.</li>
 
 </ul>
 
 
 Portanto, a alternativa correta é C.
 

</body>
</html>

De acordo com os padrões GRASP, a função do low coupling
é garantir que o acoplamento entre classes ou entidades
permaneça fraco, de forma a permitir a maior reutilização
possível.

Considerando os conceitos de análise e projeto orientados a objetos,
julgue os itens subsecutivos.


<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 math {
 font-size: 16px;
 }
 </style>
</head>
<body>
 Para resolver essa questão sobre padrões de projeto, especialmente em um contexto onde o custo de criação de objetos é elevado e é necessária a otimização de recursos, vamos explorar o padrão de projeto adequado.
 
 
 Padrões de Projeto são soluções reutilizáveis para problemas comuns em design de software. Os padrões de projeto foram popularizados pelo livro "Design Patterns: Elements of Reusable Object-Oriented Software", conhecido como GoF (Gang of Four) por seus quatro autores. Eles são uma parte essencial do desenvolvimento de software e ajudam a tornar o software mais robusto, limpo e eficiente.
 
 
 Explorando os padrões citados nas alternativas:
 
 
 <ul>
 <li>A) Facade:
 Fornece uma interface simplificada para um conjunto de outras interfaces em um sistema. É uma boa escolha quando estamos lidando com um sistema complexo, mas não é utilizado para controlar a instância de criação de objetos, e sim simplificar a comunicação entre componentes.
 </li>
 
 <li>B) Mock Object:
 É mais aplicado em contextos de teste, onde simula o comportamento de objetos reais de maneira controlada. Não se aplica ao problema de otimização de recursos na instância de objetos.
 </li>
 
 <li>C) Singleton:
 Este padrão garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a ela. Embora este padrão esteja relacionado à criação de instâncias, ele é utilizado onde apenas uma instância do objeto deve ser criada, não otimizando caso múltiplas instâncias diferentes sejam necessárias.
 </li>
 
 <li>D) Lazy Loading:
 Este padrão é utilizado especificamente para adiar a inicialização de um objeto até o ponto muito necessário. É extremamente útil em situações onde a criação de objetos é custosa em termos de recursos e não precisamos de todas as instâncias de objetos de uma vez.
 </li>
 
 <li>E) Method Chaining:
 Refere-se a uma técnica de programação que permite chamar múltiplos métodos em um único objeto sequencialmente. Este padrão está mais relacionado a melhorar a legibilidade e a eficiência do código, mas não aborda diretamente a questão da criação eficiente de objetos.
 </li>
 </ul>
 
 
 Portanto, de acordo com o enunciado que enfatiza a necessidade de otimizar a criação de objetos devido aos altos custos associados, o padrão de projeto mais adequado é o Lazy Loading. Este padrão não só adia a criação do objeto até que seja absolutamente necessário, mas também é uma estratégia eficaz para a gestão eficiente da memória e outros recursos em um sistema.
 

 Portanto, a alternativa correta é D.
 

</body>
</html>

Padrões de Concepção (conception), Padrões 
Organizacionais (organizational) e Padrões 
Normativos (normative)

Padrões de Concepção (conception), Padrões 
Organizacionais (organizational) e Padrões 
Comportamentais (behavioral)

Padrões de Criação (creational), Padrões Estruturais (structural) e Padrões Normativos (normative)

Padrões de Criação (creational), Padrões Estruturais (structural) e Padrões Comportamentais (behavioral)

<!DOCTYPE html>
<html lang="pt-BR">
<head>
 <meta charset="UTF-8">
 <style>
 body {
 font-size: 16px;
 line-height: 1.5;
 }
 .blue {
 color: blue;
 }
 </style>
</head>
<body>
 Os padrões de projeto conhecidos como GoF (Gang of Four) são essenciais para a compreensão de soluções padronizadas em desenvolvimento de software. Eles estão classificados em três categorias principais: padrões de criação, padrões estruturais e padrões comportamentais.
 
 
 Essas categorias se distinguem pelo tipo de problema que visam solucionar:
 
 
 <ul>
 <li>Padrões de Criação (Creational):
 Focam na maneira como os objetos podem ser criados. Esses padrões ajudam a tornar um sistema independente de como seus objetos são criados, compostos e representados. Exemplos incluem Singleton e Builder.
 </li>
 </ul>
 

 <ul>
 <li>Padrões Estruturais (Structural):
 Estes padrões lidam com a composição de classes ou objetos para formar estruturas maiores. O objetivo é determinar como as classes herdam umas das outras e como elas são compostas de outras classes. Exemplos incluem Adapter e Decorator.
 </li>
 </ul>
 

 <ul>
 <li>Padrões Comportamentais (Behavioral):
 Concentram-se nos algoritmos e na atribuição de responsabilidades entre os objetos. Eles caracterizam não apenas os padrões de objetos ou de classes mas também os padrões de comunicação entre eles. Exemplos incluem Observer e Strategy.
 </li>
 </ul>
 

 Analisando cada uma das alternativas fornecidas, temos:
 
 
 <ul>
 <li>A) Padrões de Concepção (conception), Padrões Organizacionais (organizational) e Padrões Normativos (normative):
 Incorreta. Esta alternativa introduz categorias que não são usadas na classificação dos padrões de projeto GoF.
 </li>
 
 <li>B) Padrões de Concepção (conception), Padrões Organizacionais (organizational) e Padrões Comportamentais (behavioral):
 Incorreta. Embora mencione os padrões comportamentais, as outras duas categorias não são reconhecidas na literatura de padrões de projeto GoF.
 </li>
 
 <li>C) Padrões de Criação (creational), Padrões Estruturais (structural) e Padrões Normativos (normative):
 Incorreta. Inclui uma categoria "normativos", que não é reconhecida nos padrões de projeto GoF.
 </li>
 
 <li>D) Padrões de Criação (creational), Padrões Estruturais (structural) e Padrões Comportamentais (behavioral):
 Correta. A alternativa lista as três classificações corretas para os padrões de projeto GoF, conforme os fins que os padrões visam atingir.
 </li>
 </ul>
 

 Portanto, a alternativa correta é D.
</body>
</html>

Questões de Tecnologia da Informação - Padrões de projeto GoF