No meio, tais padrões são tratados como Padrões de Projeto que, de uma forma ampla, caracterizam uma forma segura de desenvolvimento pautada em situações já experimentadas no mundo real, o que tende a evitar problemas ocasionais, contribuindo para um processo de desenvolvimento bastante eficaz.
Em meio aos diversos padrões existentes, o MVVM é um padrão que trata da arquitetura do software, incidindo diretamente em seu aspecto construtivo. Assim, o presente artigo tem como foco sua explanação e empregabilidade no contexto do Delphi, numa abordagem essencialmente direcionada a este tipo de desenvolvedor.
Apesar de não tão recorrente, o tema MVVM já foi abordado anteriormente em algumas ocasiões aqui mesmo nesta revista. Assim como esperado, tais abordagens tiveram como foco a apresentação da verdadeira essência deste padrão, conceituando o leitor numa tomada bastante abrangente, sem restrições.
Como fruto disso, a plena assimilação dos conceitos provia a empregabilidade do MVVM em diversos cenários, independente de linguagem ou tecnologia. Apesar de eficaz, o uso de padrões deste tipo acaba por imprimir, naturalmente, diversas barreiras ao desenvolvedor Delphi tradicional.
Aqui, considera-se tradicional o programador que faz uso efetivo do poder RAD provido pela ferramenta, por meio do uso dos componentes disponibilizados, codificação de seus eventos, entre outros hábitos.
A partir disso, nota-se que grande parte da comunidade acaba por se encaixar neste agrupamento, que não vê nos padrões de projeto, tal qual o MVVM, algo essencial ou de importância para seu uso habitual. Logo, por esta razão, o entendimento do assunto torna-se bastante prejudicado.
Diante disso o presente artigo vai na contramão do paradigma “essencial”, uma vez que se restringe ao contexto Delphi, como linguagem e tecnologia, provendo o assunto de uma forma singular, por meio do bordão “MVVM para programadores Delphi”.
Tudo isso com o intuito de simplificar tanto a assimilação do tema, quanto o emprego prático do mesmo, sempre tendo como base a possível visão de um programador desta comunidade. Por se tratar de um assunto não tão comum na comunidade Delphi, neste início de abordagem, torna-se imprescindível a explanação de toda a parte conceitual relacionada ao tema.
Uso da POO no desenvolvimento Delphi
No ramo da programação, a Orientação a Objetos, ou simplesmente OO, é um paradigma que estabelece a projeção e construção de softwares a partir de um agrupamento de unidades sistêmicas que interagem entre si, na busca por atender um fim em comum.
Cada unidade desta é então tratada como “objeto”, oriundo de um elemento mais abrangente denominado “classe”. Neste cenário, uma aplicação pode conter um conjunto de classes implementadas, cada qual determinando os eventuais comportamentos (por meio de métodos) e estados (por meio de atributos) de um tipo especificado de objeto.
Logo, toda essa relação entre classes e objetos é comumente resumida na seguinte afirmação: “um objeto nada mais é do que uma instância de uma classe”.
O Delphi, sendo uma linguagem OO, também oferece a seus desenvolvedores recursos suficientes para a construção de softwares apoiados no paradigma da POO. Apesar disso, tendo em mente um desenvolvimento mais “tradicional”, baseado no arrastar e soltar de componentes para formulários e codificação de eventos, todo o conceito da POO fica restrito apenas aos bastidores da construção. Em outras palavras, isso significa dizer que mesmo nessas situações, de forma indireta, o desenvolvedor acaba por fazer uso da orientação a objetos em seu processo desenvolvimento.
Como exemplo, um componente TButton arrastado para um Form fundamenta um objeto, uma vez que formaliza uma instância da classe TButton. Em contraponto, a essência mais purista da POO não é realmente explorada nessas construções, favorecendo o desenvolvedor a abdicar da criação de suas próprias classes e, em consequência, seus próprios objetos.
Em vista disso, o
uso de padrões de projeto, que por sua própria natureza já são enraizados na
POO, tende a se tornar algo dificultoso para um desenvolvedor Delphi
“tradicional”. Isto porque, o mesmo acaba por não conseguir empregar uma
técnica que irá lidar com classes e objetos, cujas atividades não faze ...
