Utilidade do Proxy

Olá Paulo Cesar !

Como o modelo em um sistema possui o maior índice de reutilização, quanto mais código ou lógica de negocio colocarmos nela, mais difícil e complexo fica para alterá-la. A intenção é deixá-la mais "pura" possível para que seja útil em diversas situações.A responsabilidade de adicionarmos comportamento ao modelo delegamos para a classe Proxy que intercepta e incluir as funcionalidades necessárias para cada tipo de domínio de negocio. Desta forma o modelo fica desacoplado da logica de negocio podendo ser utilizado em diversas situações.

Espero ter ajudado !

Eu entendi mais ou menos. Nesse sentido funcional me dá a impressão de que um Proxy seria o "Controller" da model, mas já existe NegociacoesController. Então, porque é mais lógico utilizar um Proxy para gerenciar as funções de atualização de uma model em vez de criar um Controller para isso?

Perdão se eu estiver confundindo o papel dos dois.

Obrigado!

Paulo, veja que o proxy separa bem o modelo do código de infra. Você criou a classe Negociacao, certo? Ela esta amarrada com algum código para atualizar a view, há algum código especial nela? Não, apenas JavaScript puro. Este mesmo modelo você pode usar com Angular 1, 2, React pois é apenas um modelo.

O proxy, é um cara que encapsula o seu modelo e adiciona funcionalidades que não tem relação com o modelo. Em nosso caso, quando nosso modelo é atualizado, através do proxy atualizamos a view. Veja que isso não é papel de um modelo. No proxy, queremos tratar o proxy como um modelo (porque estruturalmente ele é), mas adicionar novas funcionalidades que não dizem respeito ao modelo, como atualização de view etc. Quem usa o proxy nem fica sabendo dessas novas funcionalidades.

Se você quiser agora usar o modelo verdadeiro em outros projetos, leva o modelo e o proxy fica, porque todo o código do proxy só existe para atender alguma coisa de infraestrutura, em nosso caso atualiza a view.

Só para concluir, a classe Negociacao deve ter regras de negócio, porque se ela tiver apenas dados, outra classe terá que operar sobre os dados da negociação o que resulta na programação procedural, ferindo o princípio de OO no qual temos dados e comportamento andando junto.

O que não pode ter em um modelo de um domínio de problema (nosso domínio de programa é negociações) é código de infraestrtura (manipular DOM é considerado um código de infra). Como o modelo é rico, ou seja, possui as regras de negócio, se você desiste do framework caseiro que fizemos e quer usar Angular, você leva o modelo com todas as regras que operam sobre ele para o mundo Angular. Angular usa outra técnica para atualizar a view com base no seu modelo.

Paulo Cezar, para ficar ainda melhor nesses conceito, sugiro a leitura do livro DOMAIN DRIVEN DESIGN do Eric Evans. Lá há termos como modelo rico, modelo pobre e debates sobre o local de regras de negócio e por ai vai.

Nossa, acho que saquei agora! No caso, se eu usasse a model com Angular 2 (inclusive farei o curso depois), o Angular teria formas equivalentes de controlar essas funções de atualizar a view?

Obrigado pelos esclarecimentos e recomendação do livro!

Isso mesmo Paulo! Perfeito, fiquei até arrepiado! Pegou a ideia. É por isso que o modelo de um domínio específico de um problema.. que possui regras desse domínio (por exemplo, uma regra é que uma negociação criada não pode ser alterada para não ter fraude) pode ser reutilizada em qualquer outro sistema porque não esta amarrado a qualquer framework.

Se você amarra um modelo a um framework, você só poderá utilizá-lo nesse framework. Se trocar de framework, terá que reescrever o código do zero.

Então, em nosso exemplo, se você leva o modelo do Negociacao para usar com React, por exemplo, como ele não esta amarrada a nenhum código de atualização de view e coisa parecida, por ser usado e reaproveitado no React. Sendo assim, perdemos apenas o código do proxy, que não possui regra de negócio, mas código de atualização de view em nosso caso.

Sendo assim, a beleza do proxy é que você pode trará-lo como se fosse um objeto do modelo durante toda a aplicação porque ele é um cara mentiroso. Toda vez que você interage com o proxy achando que é o modelo real.. algum código pode ser executado, em nosso caso, atualizaremos a view.

Tranquilão? Fechamos essa dúvida?

Fechou! Seria legal se houvesse cursos que tratam especificamente desses padrões de desenvolvimento. Sempre são de encher os olhos!

Até mais!

Seria os cursos de Design Patterns.

Joao, eu vi alguns de diferentes linguagens, e embora eu saiba que a linguagem não altera o teor informativo sobre patterns, será que existe algum curso para linguagens front-end? Ou eles não fariam sentido mesmo?

Abs.

Agora com o ECMAScript 6 o javascript esta bem legal para praticar os Design Patterns. Tem também o TypeScript(utilizado no curso de angular 2) que esta bem parecido com o Java e C#,pegue uma linguagem OO que te agrade e cai pra dentro.

Um abraço !