Fala Radizeiro e Radizeira, tudo bem com vocês?
Aqui nesta nossa série de post aqui no blog, tenho mostra como é possível melhor a qualidade de seus códigos utilizando as boas práticas.
E mostrando como é importante o desacoplamento de nossos códigos, e a possibilidade de criação de novas funcionalidades e rotinas, sem dores.
Se hoje você tem sentido dificuldades em aplicar novas funcionalidades em seus softwares, ou até mesmo, aplicar algumas atualizações, sejam elas em rotinas fiscais ou inclusão de novas tecnologias.
Cada nova regra do governo, ou de alguma plataforma que esteja utilizando, é uma dor de cabeça, e um sofrimento para atualizar.
Isso se dá pelo simples fato de estar 100% acoplado, utilizando componentes em tudo que é lugar em seu projeto, e não te dando a possibilidade de poder fazer uma alteração simples.
Por este motivo você irá sempre me ver falar sobre a aplicabilidade das boas práticas, na importância da usabilidade de seus software, e claro na qualidade de vida, sua e de seus colaboradores.
É muito importante essa preocupação com o seu código.
E no post de hoje dando continuidade no que vimos anteriormente, estarei criando mostrando para vocês a criação de uma fábrica de query.
Isso mesmo, uma fábrica, onde irei mostrar o uso do padrão de projeto Factory.
Eu poderia instanciar a query diretamente no create dessa minha classe e já ir utilizando a classe de query, mas isso não é uma boa prática, pois iremos ter um acoplamento.
E acabamos fugindo da regra de não criar acoplamento.
Para isso irei criar uma nova classe que irei chamá-la de ControllerFactoryQuery, ou seja, uma classe da camada de Controller, que será a fábrica da query.
Observe que tenho uma interface chamada iFactoryQuery que só tem um método para que as classes construtoras possam implementar.
E para que não fique misturado com as outras interfaces, foge um pouco da regra, pois estou trabalhando com a camada de Controller, e as demais interfaces criadas fazem parte da camada Model.
Para isso irei criar uma nova unit e irei chamá-la de Usuario.Controller.Factory.Interfaces.
iFactoryQuery = interface function Query(Connection : iConexao) : iQuery; end;
Todas as vezes que nos deparamos com um acoplamento, precisamos subir o nível de abstração.
Então eu estou criando uma fábrica, que irá prover um objeto de query.
Isso foi feito para que eu não fique dependente do meu componente de conexão.
type TControllerFactoryQuery = class(TInterfacedObject, iFactoryQuery) private public constructor Create; destructor Destroy; override; class function New : iFactoryQuery; function Query(Connection : iConexao) : iQuery; end; implementation constructor TControllerFactoryQuery.Create; begin end; destructor TControllerFactoryQuery.Destroy; begin inherited; end; class function TControllerFactoryQuery.New : iFactoryQuery; begin Result := Self.Create; end; function TControllerFactoryQuery.Query(Connection : iConexao) : iQuery; begin Result := TModelQueryFiredac.New(Connection); end;
Agora quando eu quiser utilizar uma query na minha entidade de usuário, irei chamar a fábrica de query.
constructor TModelEntidadeUsuario.Create; begin FQuery := TControllerFactoryQuery.New.Query(nil); end;
Agora minha entidade de usuário instância a query, mas ela não sabe qual componente query está utilizando.
Agora para que possamos nos situar.
O que estamos fazendo aqui nesse nosso exemplo?
Nós criamos uma classe de conexão, que utilizamos o Firedac, visto neste post aqui.
Criamos uma classe totalmente independente, responsável simplesmente por criar um FDConnection.
E também temos uma classe do Firedac, só que especificamente para a query, que pode ser visto nesse post.
Onde temos também essa classe completamente independente, responsável apenas de criar uma FDQuery, que recebe uma injeção de dependência, através de uma conexão através da interface.
Em seguida, eu criei uma entidade de usuário, que pode ser visto também nesse post.
E nessa entidade ela precisa de uma query, só que eu não trabalho diretamente com a query do Firedac.
Isso se dá pelo fato de mantermos a redução de acoplamento.
Fazendo assim podemos trocar de forma fácil e rápida do Firedac, para qualquer componente de acesso.
Dessa forma que criamos aqui nessa nossa série de post, podemos alterar o driver de conexão a hora que precisarmos, sem ter que alterar todo o projeto.
Simplesmente criamos uma classe que instancia esse driver de conexão, e pronto, todo o projeto já está utilizando, sem ter a dor de ter que alterar todo o projeto.
Isso se dá pelo fato de que todo o projeto estar trabalhando orientado a Interface, e dessa forma reduzindo o acoplamento e dando a possibilidade de atualizar a classe query e a de conexão, sem dores de cabeça.
Como a minha entidade está requisitando uma fábrica, e a fábrica está trabalhando com a interface de iQuery, não ficamos presos a componentes, sendo assim as alterações são menos custosas.
Viu como as coisas vão melhorando quando reduzimos o acoplamento?
Fazendo assim você não tem dores em caso de ter que alterar seu driver de conexão.
