Questões de Concurso sobre Padrões estruturais

O desacoplamento entre View e ViewModel é comumente implementado através de padrões de observabilidade, onde a View assina fluxos de dados expostos pela ViewModel.

É uma evolução da arquitetura MVC (Model-View-Controller) adaptada para a arquitetura WPF e Silverlight.

Elimina o uso de Activities e Fragments na camada de View tornando a implementação mais simples.

A camada Model é acoplada à camada View, o que facilita a troca de mensagens entre as duas camadas.

Os modelos de dados são acessados diretamente pela camada View, sem a necessidade de mediação do ViewModel, de forma semelhante ao que ocorre em arquiteturas como MVC e MVP.

I, apenas.

I e II, apenas.

I e III, apenas.

II e III, apenas.

I, II e III.

estabelecer um catálogo técnico com padrões locais para cada sistema e permitir que as equipes implementem integrações ponto a ponto conforme necessidade, priorizando adaptações rápidas sobre conformidade a padrões amplos.

priorizar a substituição de todos os sistemas legados por soluções comerciais prontas (SaaS) sem padronização interna, contando com contratos individualizados para resolver integração e governança caso a caso de forma ágil.

centralizar todas as decisões em um comitê técnico sem participação das áreas de negócio, para acelerar padronizações técnicas, deixando a definição de processos e indicadores de valor para um momento posterior.

basear-se em um mapa de capacidades, princípios e padrões, adotando padrões de interoperabilidade nacionais, políticas de governança, catálogo de serviços, um roadmap por capacidades que priorize redução de redundâncias, eficiência operacional e sustentabilidade tecnológica.

focar apenas a otimização operacional diária (rotinas e scripts), com manutenção evolutiva dos legados por iniciativa das equipes, incorporando padrões de interoperabilidade apenas quando houver falhas críticas.

é fornecida uma interface para criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes concretas

define-se um esqueleto de algoritmo e de uma aplicação, usando de postergação para confeccionar operações de subclasses

um objeto possuirá apenas uma única instância, sendo que uma classe irá gerar apenas um objeto, disponível de forma única para todo o escopo da aplicação

seja necessário converter a interface de uma classe para outras interfaces, sendo estas determinadas de modo múltiplo pelos clientes da classe principal

cria-se um objeto intermediário, entre um objeto base e seus clientes, sendo que estes não têm uma referência direta para o objeto base, só para o intermediário

O padrão fachada converte a interface de uma classe para outra interface esperada pelo cliente (uma fachada), permitindo que componentes com interfaces compatíveis colaborem sem alteração no cliente que consome a nova interface.

O padrão proxy acrescenta novas responsabilidades ao objeto em tempo de execução, por meio de múltiplos proxies, podendo inclusive alterar a interface exposta ao cliente para refletir as responsabilidades adicionadas.

O padrão decorador propõe o uso de composição para adicionar novas funcionalidades dinamicamente em classes bases, representando uma alternativa a herança quando se precisa adicionar tais funcionalidades a uma classe base.

O padrão adaptador fornece uma interface única e simplificada para um conjunto de classes de um subsistema complexo, reduzindo o número de interações do cliente e escondendo detalhes internos do subsistema atrás de um “adaptador”.

Certo

Errado

é organizada exclusivamente em grupos de processos e áreas de conhecimento

é baseada em princípios de gerenciamento de projetos e em domínios de desempenho

apresenta um conjunto fixo de métodos e ferramentas obrigatórios para todos os projetos

restringe a aplicação do guia a projetos de tecnologia da informação, dada sua ênfase em métodos ágeis

Princípio da substituição de Liskov.

Princípio da inversão de dependência.

Princípio da segregação de interfaces.

Princípio aberto/fechado.

Princípio da responsabilidade única.

Micro Stack

Service Stack

Monolithic Stack

Application Group Stack

O limite máximo de aninhamento (nesting) é de 128 níveis.

O limite máximo de aninhamento (nesting) é de 32 níveis.

O limite máximo de aninhamento (nesting) é de 64 níveis.

O limite máximo de aninhamento (nesting) é de 256 níveis.

Não há limite máximo definido para aninhamento (nesting).

isolar completamente a Lógica de Domínio dos detalhes de implementação de infraestrutura e agentes externos.

garantir a comunicação direta e otimizada entre o domínio e o banco de dados.

permitir que o domínio seja desenvolvido em uma linguagem de programação diferente da usada nos adaptadores.

simplificar o deploy da aplicação, eliminando a necessidade de containers.

impor o uso de Padrões de Projeto Estruturais como Adapter e Facade, em todo o sistema.

Factory Method, Abstract Factory, Builder.

Command, Interpreter, Chain of Responsability.

Adapter, Bridge, Composite.

Anti-Patterns.

Motivation, Diagrams, Proposal.

Certo

Errado

Adapter, Bridge, Composite, Decorator, Façade, Proxy.

Memento, Observer, Bridge, Composite, Decorator.

Factory Method, Abstract Factory, Composite, Façade, Proxy.

Interpreter, Template Method, Factory Method, Abstract Factory, Decorator.

Chain of Responsibility;

Prototype;

Decorator;

Abstract Factory;

Factory Method.

Certo

Errado

Visitor

Façade

Singleton

Composite

Factory Method

Strategy, Composite e Prototype.

Decorator, Bridge e Adapter.

Adapter, Composite e Visitor.

Singleton, Adapter e Observer.

Builder, Visitor e Composite.

Adapter, Command, Interpreter e Singleton.

Composite, Observer, Strategy e Singleton.

Adapter, Decorator, Flyweight e Proxy.

Composite, Visitor, Observer e Proxy.

bridge, composite, facade

abstract factory, builder

factory method, prototye, singleton

interator, mediator, visitor

memento, state, strategy