Programação O-O: Evitando VOs (Classes de dados) e BOs (classes de negocio)

Recentemente li sobre este assunto no link:
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Resumo do meu entendimento sobre este artigo

Muitos programadores, por terem aprendido de forma errada o paradgma de programação Orientada a Objetos, passaram a utilizá-la como se esta fosse apenas mais uma ferramenta de desenvolvimento. É o caso, por exemplo, de quem programava em Pascal e passou a programar em Delphi, o qual, por sua vez, nada mais é do que Pascal Orientado a Objeto. O mesmo caso também para quem programava em C e passou a programar em Java.
Uma das causas desse problema foi a criação do conceito de Enterprise Java Beans (EJB), que segundo o artigo, são os "componentes distribuídos que talvez tenham no curriculum o maior número de enganos históricos da indústria" com relação ao uso de Orientação a Objetos. Muitos programadores que desenvolvem em Java EE, não conseguiram assimilar corretamente este novo conceito e passaram a utilizar o paradgma O-O de forma errada, gerando com isso, um consenso equivocado entre eles.
Para tentar minimizar este problema a SUN lançou um catálogo de padrões chamado de Core J2EE Patterns". A maior parte deste catálogo se destina a lidar com problemas que EJBs causam, mas o nome “core” ajudou a difundir o mito de que Java EE era sinônimo de EJBs ", causando, em parte, um efeito contrário, ao gerar ainda mais confusão na cabeça de alguns desenvolvedores.
Um dos padrões do catálogo da SUN, que se chamava VO (Value Object), passou a se chamar TO (Transfer object). Um TO, que nada mais é do que a classe que possui os métodos GETs e SETs, seria um objeto cuja função é transportar dados entre classes. Toda vez que a TO precisar buscar dados no servidor para serem manipulados pela aplicação, deverá fazer uma conexão na rede com o banco de dados, esse procedimento gera várias conexões com o banco e conexões consomem recursos, diminuindo assim o desempenho da aplicação, além de aumentar o tráfego na rede.
No caso de aplicações que não precisam fazer constantes acessos a banco, o uso de TOs se torna dispensável.
Assim o artigo diz que "Eventualmente a comunidade de desenvolvedores percebeu que EJBs não são a solução para qualquer problema - na verdade são uma possível solução para uns poucos problemas".

Por definição do catálogo da SUN, ao modelarmos um sistema devemos criar as classes TOs e as BOs. As TOs são as classes de dados e as BOs as classes lógicas. As TOs transferem dados para as BOs manipulá-los, dessa forma temo a classe de dados separada da classe de lógica.
Uma das maiores vantagens da programação Orientado a Objeto é possibilitar traduzir o mundo real para um software da maneira mais próxima possível. Ao utilizar classes de dados (TOs) separadas das classes de lógica (BOs), segundo o artigo, "esta vantagem é simplesmente jogada fora" e que "No mundo real não existe lógica de um lado e dados de outro, ambos combinados forma um único conceito".
"Também a manutenção de um sistema construído desta maneira é problemática". Devido à classe BO ficar muito dependente da classe TO, a "alteração em uma afeta drasticamente a outra", o que dificulta então a manutenção de uma sistema desenvolvido dessa maneira.
"A coesão das classes de lógica (BOs) tende a ser baixa, visto que agrega diversas funções relativas não só à sua própria estrutura de dados mas também a outras classes TO.
Se uma BO pode estar ligada a diversos TOs, ao fazer uma alteração na BO deve-se verificar quais serão as TOs que sofreram o impacto dessa alteração, vindo então a dificultar a manutenção do sistema. Conforme está no artigo, "dificilmente um TO vai ser utilizado apenas por um BO (e se o for temos um problema grande de reusabilidade) ".
Tendo em vista que o BO tem acesso ao TO, fica claro então que o BO pode alterar os valores do TO, isso torna o sistema inconsistente, pois o TO deveria apenas ter a função de transferir dados e não de permitir alterações nos dados já capturados do banco.
O artigo conclui este assunto dizendo que pelo fato de muitos programadores estarem utilizando o paradgma da programação O-O apenas como ferramenta, "a grande maioria das aplicações O-O, na verdade estão sendo construídas de maneira procedural por pura ignorância ou indução da documentação existente." E sua frase final é a seguinte:
"Desenvolver sistemas envolve, antes de mais nada, conhecer a tecnologia utilizada. Não se pode tirar proveito de Orientação a Objetos se não se distingue o que é OO e o que é procedural ".