Quantos padrões de design o Magento 2 possui?
15
Padrões de Design Magento 1/2
Parte 1: MVC
O Magento utiliza um padrão MVC exclusivo, utilizando uma camada de configuração baseada em DOM. Ele utiliza o xml para direcionar a configuração e as ações do aplicativo sobre a arquitetura regular do Model-View-Controller.
Parte 2: Controlador frontal
O Magento usa o padrão Front Controller para implementar fluxos de trabalho para sua aplicação. Ele tem um único ponto de entrada (index.php) para todos os seus pedidos. Vamos ver como tudo funciona.
Parte 3: Fábrica
O método Factory é usado para instanciar classes no Magento. Você instancia uma classe no Magento chamando um método apropriado passando um nome abstrato que representa um grupo de classes seguido por um nome de classe. Grupos de classes e suas abstrações apropriadas são declarados nos arquivos XML de configuração na pasta / etc / do seu módulo.
Parte 4: Singleton
Assim como a abstração de classe de fábrica e os grupos de classe no Magento, o padrão Singleton é instanciado para blocos e classes da mesma forma.
Parte 5: Registro
O padrão de registro é basicamente um padrão que permite que qualquer objeto ou dado esteja disponível em um escopo público global para qualquer recurso usar.
Parte 6: Protótipo
O padrão Prototype no Magento é usado como uma extensão do padrão Abstract Factory. Ele garante que uma subclasse apropriada seja instanciada por meio de tipos apropriados atribuídos a um objeto. O que isto significa? Basicamente, isso significa que sempre que você precisar obter uma classe específica definida por meio de seu tipo pai, o padrão de protótipo garante que você obtenha a classe certa que pode lidar com o que você precisa.
Parte 7: Pool de Objetos
O Padrão de Conjunto de Objetos mantém os objetos prontos para uso repetidamente, em vez de re-instancia-los e destruí-los quando terminar. É uma ótima maneira de economizar no consumo de memória e calcular ciclos.
Parte 8: Iterador
O Padrão Iterador é um padrão de design que permite que um objeto atravesse os elementos de outra classe. Isso permite que você especifique um iterador e permita que vários conjuntos diferentes de dados sejam transmitidos sem alterar a estrutura subjacente que permite a iteração.
Parte 9: Carregamento lento
Lazy Loading é um padrão de design que atrasa o carregamento de um objeto até o momento em que o objeto é chamado. Com o Magento, eles não utilizam isso com objetos, mas com dados.
Parte 10: Localizador de Serviço
O localizador de serviço é um padrão de design que permite ao usuário obter um serviço encapsulando o processo dentro de uma camada de abstração. Isso permite ao usuário recuperar o serviço apropriado ou melhor sem saber o que é esse serviço em tempo de execução.
Parte 11: Módulo
O Módulo Design Pattern é uma forma de programação modular que enfatiza o agrupamento de funcionalidades de um programa em módulos independentes e intercambiáveis.
Parte 12: Observador
O padrão observador é o local em que um ouvinte de evento é definido em um determinado ponto durante a execução de um aplicativo. Outros componentes do aplicativo podem "se conectar" a esse ouvinte de evento e executar seu código durante esse ponto.
Parte 13: Registro ativo
Objetos são uma representação de uma linha na tabela do banco de dados. Esses objetos devem ter propriedades que refletem as colunas que representam a estrutura da tabela e métodos para permitir modificações dessas propriedades no banco de dados.
O uso do padrão pelo Magento
As classes que herdam após a classe Mage_Core_Model_Abstract têm acesso aos métodos load (), save () e delete () que permitem carregar, modificar, criar ou excluir registros em uma tabela à qual a classe está conectada. Além disso, a classe Mage_Core_Model_Abstract herda de Varien_Object, que nos dá acesso a métodos verdadeiramente mágicos __set () e __get () responsáveis pelo mapeamento automático de colunas em uma tabela de banco de dados com as propriedades de um determinado objeto.
Adição Magento 2
PADRÃO DE CONCEPÇÃO DE SERVIÇO
O Magento é um sistema modular ou baseado em extensão, que permite que um desenvolvedor de terceiros personalize e substitua partes principais de sua estrutura. Essas personalizações podem levar a vários problemas, por exemplo, será necessário que os desenvolvedores acompanhem a personalização feita por extensões externas. Assim, para superar esse Magento, surge um padrão de contrato de serviço. Um contrato de serviço é um conjunto de interfaces que atuam como uma camada entre um usuário final e uma camada de negócios. Portanto, em vez de expor diretamente a lógica de negócios para personalização do usuário final, existe uma camada chamada contrato de serviço.
Os contratos de serviço aprimoram a modularidade do Magento. Ajuda os comerciantes a atualizar facilmente o Magento Garanta uma API bem definida e durável, implementada por outros módulos externos e Magento. Forneça uma maneira fácil de expor a lógica de negócios por meio de interfaces REST ou SOAP.
GERENTE DE OBJETOS
Ele próprio consiste em vários padrões, como: - Injeção de dependência, Singleton, Fábrica, Abstract Factory, Composto, estratégia, CQRS, Decorator e muitos outros. Discutiremos alguns dos padrões mais usados entre estes. O gerenciador de objetos tem um papel muito importante a desempenhar, o Magento proíbe o uso direto dele. O gerenciador de objetos é responsável pela implementação de padrões de fábrica, singleton e proxy. Instancia automaticamente o parâmetro nos construtores de classe. Antes de avançar, vamos entender sobre objetos injetáveis e não injetáveis: -
OBJETOS INJETÁVEIS
Eles não têm sua própria identidade, como EventManager, CustomerAccountManagementService.
OBJETOS NÃO INJETÁVEIS
Como cliente, produto etc. Essas entidades geralmente têm suas identidades e estado, uma vez que têm suas identidades, é importante saber em qual instância exata da entidade temos que trabalhar.
INJEÇÃO DE DEPENDÊNCIA
É uma alternativa ao Mago no magento 1. É um conceito de injetar o objeto dependente através do ambiente externo, em vez de criá-lo internamente. Portanto, solicitaremos recursos quando nosso objeto estiver sendo criado, em vez de criar recursos quando necessário. Isso ajuda nas modificações e testes futuros que se tornam muito fáceis ao zombar dos objetos necessários.
PADRÃO DE FÁBRICA OU CLASSES DE FÁBRICA:
No Magento 2 Factory, as classes criam uma camada entre o gerenciador de objetos e o código comercial. As classes de fábrica não precisam ser definidas explicitamente, pois são geradas automaticamente. Devemos criar classes de fábrica para objetos não injetáveis.
PADRÃO DE PROXY
As classes de proxy são usadas para trabalhar no lugar de outra classe e no Magento 2 às vezes são usadas no lugar de classes com fome de recursos. Para entender quais classes de proxy, vamos ver o motivo que leva à ocorrência de classes de proxy. Como sabemos, o Magento usa injeção de construtor para criação de objetos e quando instanciamos um objeto, todas as classes em seu construtor também instanciam, levando a uma cadeia de instanciação por meio de um construtor, isso pode realmente retardar o processo e afetar o desempenho de uma aplicação , para interromper a instanciação em cadeia, o Magento usa classes de proxy.
Vamos ver o seguinte código: -
Magento\Catalog\Model\Product\Attribute\Source\Status\Proxy
Magento\Catalog\Model\Product\Link\ProxyPortanto, no código acima, estamos usando classes de proxy para catalogProductStatus e productLink. Quando corremos
php bin/magento setup:di:compile O Magento cria classes de proxy dinamicamente usando di.xml com algumas convenções fixas, substituindo assim o objeto original por um objeto de classe proxy. Agora, vejamos nossa classe proxy para entender como ela está funcionando.
Algumas convenções comuns que o Magento seguem durante a criação do proxy: -
Plugins (interceptores)
Visão geral
Um plug-in, ou interceptador, é uma classe que modifica o comportamento das funções de classe pública, interceptando uma chamada de função e executando o código antes, depois ou ao redor dessa chamada de função. Isso permite substituir ou estender o comportamento de métodos públicos originais para qualquer classe ou interface.
Extensões que desejam interceptar e alterar o comportamento de um método público podem criar uma classe Plugin que são chamadas de plugins.
Essa abordagem de interceptação reduz conflitos entre extensões que alteram o comportamento da mesma classe ou método. Sua implementação de classe Plugin altera o comportamento de uma função de classe, mas não altera a própria classe. Como eles podem ser chamados sequencialmente de acordo com uma ordem de classificação configurada, esses interceptores não entram em conflito um com o outro.
Limitações
Os plug-ins não podem ser usados com nenhum dos seguintes itens:
ObjectManager
Visão geral
Aplicativos grandes, como o aplicativo Magento, usam um gerenciador de objetos para evitar o código padrão ao compor objetos durante a instanciação.
Na estrutura do Magento, a implementação do ObjectManagerInterface executa as tarefas de um gerenciador de objetos.
Responsabilidades
O gerenciador de objetos tem as seguintes responsabilidades:
Criação de objetos em fábricas e proxies. Implementando o padrão singleton retornando a mesma instância compartilhada de uma classe quando solicitado. Gerenciamento de dependência instanciando a classe preferida quando um construtor solicita sua interface. Instanciando parâmetros automaticamente em construtores de classe. https://devdocs.magento.com/guides/v2.0/extension-dev-guide/object-manager.html