Você precisa fazer um relatório financeiro num sistema que possui o código Orientado a Objetos.
Quais Classes e Objetos você precisa criar para representar os dados que serão exibidos no relatório?
Nenhuma!
Nenhuma Classe que representa dados é necessária. Use apenas… dados.
Muitos programadores (ainda) confundem conceitos tão distintos. Dados e Objetos são coisas completamente diferentes.
Enquanto Objetos são criaturas vivas. Dados são apenas registros do passado.
Relatórios tabulares, por exemplo, consistem apenas de exibição e formatação de dados no formato de tabela. Não precisamos de Objetos, comportamento ou encapsulamento para fazer essa tarefa — a não ser para obter os dados no lugar onde estão armazenados.
Objetos, no entanto, podem representar dados na forma de uma
Entidade
que encapsula os dados. Poderíamos ter uma Classe TFinanceReport,
por exemplo, que representa um
relatório,
porém onde estariam os dados? Em atributos? Não, não especificamente.
Imagine ter um atributo para cada coluna. Listas de objetos. Listas de listas…
No fim estaríamos trabalhando com objetos anêmicos que só possuem Métodos Getters e Setters.
Isso não seria nada eficaz devido ao grande trabalho que iria ser codificar essas Classes — muitas delas — e fazer a manipulação de seus Objetos. A performance, também, seria drasticamente afetada.
Além disso essa abordagem é totalmente contra os princípios da verdadeira Orientação a Objetos.
Mas não é assim que codificamos no Object Pascal, certo?
Estou ciente de que utilizar Objetos e listas de Objetos para exibição de relatórios não é um padrão muito utilizado no mundo Object Pascal. Vemos isso mais no mundo Java ou C#. Nesses ambientes muitos programadores acham que por estarem utilizando Objetos, eles estariam programando Orientado a Objetos, o que não é, necessariamente, uma verdade.
Programadores Object Pascal — maioria — são orientados a Dados e não a Objetos. Utilizam a abordagem RAD. Dropam componentes nos formulários, fazem algumas ligações e isso é o suficiente para a exibição dos dados em uma Grid.
Eu sou contra a abordagem RAD para Regras de Negócio ou para qualquer módulo que exija alguma inteligência, onde o encapsulamento e uso de Objetos iria me proporcionar um maior controle e manutenibilidade.
Porém sou completamente a favor da abordagem RAD se estivermos falando sobre exibição de dados.
Não tem nada de errado em utilizarmos queries para obter os dados de um SGBD e exibir o resultado diretamente na tela ou relatório.
Dados são apenas registros. Estejam eles gravados em arquivos, Banco de Dados, em streams em memória ou provenientes de uma requisição HTTP via Web, não importa. São dados, não Objetos.
Portanto não trate Objetos como um balde de dados e não trate os Dados como se fossem Objetos que pensam e tomam decisões.
Até logo.
