Na programação de banco de dados, existe uma técnica chamada "normalização" que você faz para os dados que deseja armazenar.

Alguém já tentou aplicar esse conceito ao design de objetos? Como você? Como isso funcionou?

Editar: para expandir / esclarecer, a normalização do banco de dados é mais do que um conjunto de princípios para reduzir a redundância. Na verdade, existem etapas e estágios pelos quais você passa e, pelo menos, medidas moderadamente objetivas que indicam em que estágio você está. O design de objetos tem seus próprios princípios e o conceito de olfato, mas existe alguma maneira de fazer algo semelhante que lhe diga que você está na forma XX0,1,2 ... etc ... e métodos para passar para o próximo nível mais "normalizado"?

Embora algumas das tensões subjacentes que conduzem à normalização do banco de dados não estejam presentes em um sistema OO, outras estão. Isso deu origem a padrões e princípios de projeto de OO que são, de certa forma, análogos à normalização, pelo menos na medida em que os sistemas OO são análogos aos bancos de dados relacionais. Por exemplo:

• Princípio da responsabilidade única
• Separação de preocupações
• Uma vez e apenas uma vez , também conhecido como DRY

Em outras palavras, alguém tentou aplicar técnicas de normalização de banco de dados ao OOP? Não, porque o OOP já possui soluções para os problemas compartilhados que a normalização resolve para bancos de dados relacionais.

Sim, sim eu tenho

Fiquei quieto sobre esse assunto por um longo tempo; é hora de falar.

• Alguém já tentou aplicar esse conceito ao design de objetos?

Sim. Trabalho na formalização da normalização de objetos (e, portanto, da teoria orientada a objetos subjacente) há mais de 20 anos.

• Como você?

Ao perceber que dados e código são intercambiáveis, pelo menos em teoria. Isso significa que os princípios de normalização e as operações relacionais podem se aplicar ao código e aos dados.

• Como isso funcionou?

Até agora, funcionou muito bem - acredito que as idéias obtidas foram as "armas secretas" de minhas habilidades de design, análise e refatoração.

Eu não disse nada sobre isso publicamente antes disso, porque achei que eventualmente teria tempo para concluir a pesquisa - e produzir as ferramentas implícitas - eu mesmo.

Mas cheguei à conclusão de que, com tudo o mais acontecendo na minha vida que é mais importante, mais divertido e / ou mais lucrativo, não terei tempo para terminar a pesquisa. Sempre. Há também a possibilidade significativa de que eu simplesmente não possua a base teórica necessária para concluir o trabalho sozinha.

Eu perguntei na universidade local sobre o patrocínio de um ou dois candidatos a PhD, se eles gostariam de abordar a causa, mas, infelizmente, a nossa universidade local não ensina uma base adequada na semântica da linguagem de programação.

Houve alguma pesquisa interessante nessa área, mas tudo - que eu sei - ficou aquém do esperado. Ou assume incorretamente que, como a normalização vem de um fundo relacional, ela não se aplica a modelos orientados a objetos, ou assume que a normalização se aplica apenas aos dados definidos pelos objetos. No entanto, existem alguns projetos near-miss muito interessantes ...

O material realmente interessante acontece quando você aplica a normalização ao código - o que eu argumentaria ser a base de toda refatoração .

Então agora estou pensando que a melhor coisa a fazer é divulgar, talvez pedindo para falar no DevDays 2011 em DC, e descobrir se há uma comunidade tão empolgada com essas coisas quanto eu.

Aqui está uma prévia: Normalização é o processo de tornar algo mínimo e não redundante. O princípio Não se repita (DRY) da programação orientada a objetos é, portanto, uma manifestação clara dos objetivos da normalização. Acredito que posso mostrar que todos os conhecidos princípios de design / programação / refatoração orientada a objetos são a consequência lógica da normalização de objetos. Eu acho que também posso mostrar que há coisas mais interessantes que podem ser feitas com sistemas no Object Normal Form (ONF) do que apenas refatorar.

Isso começou como um comentário sobre a excelente resposta de Rein Henrich , mas ficou muito tempo ...

A normalização se aplica aos dados relacionais. É usado para evitar duplicação, o que facilita a garantia da integridade dos dados, pois cada dado é armazenado em apenas um local. Você normaliza um banco de dados encontrando violações de um formulário normalizado e corrigindo-as.

A Programação Orientada a Objetos se aplica a operações em dados. Destina-se a agrupar maneiras de manipular dados juntos. Você pode aplicar técnicas semelhantes às classes para eliminar métodos duplicados, talvez observando quais dados a operação manipula ou depende. Por exemplo, 1NF em uma perspectiva de OO não teria nenhuma operação duplicada dentro de uma classe. 3NF pode corresponder a uma boa estrutura de herança na qual o código comumente usado está em uma superclasse. Tenho certeza de que você também poderia encontrar um local para a injeção de dependência. Você alcança um design melhor (embora nada como formas normais ainda tenha sido descoberto) ao encontrar violações dos bons princípios de design e refatoração.

Na verdade, não existem métodos algorítmicos para alcançar um bom design nos dois países. Como Rein Hendrichs aponta, existem muitos princípios que podem identificar problemas em potencial (também conhecidos como odores de código). Padrões de design e práticas recomendadas são algumas das maneiras pelas quais as pessoas tentaram resolvê-los. O desenvolvimento orientado a testes tenta localizá-los cedo, exercitando o código como será externamente. Assim como no desenvolvimento de banco de dados, a melhor solução é encontrada com experiência e análise.

Uma abordagem muito boa para projetar objetos de modelo de negócios semelhantes à normalização é a UML Modeling in Color .

É uma estratégia de design encontrada por Peter Coad que ajuda a abstrair os objetos do modelo de negócios.

Infelizmente, o livro - Modelagem de Java em cores com UML: Componentes e processos corporativos - está esgotado e você só pode comprar os usados.

Existem alguns artigos na internet sobre essa técnica.

Se você estiver familiarizado com o design relacional, encontrará a Modelagem UML em cores útil para guiá-lo:

• Peter Coad's 'Modeling in Color' - Notas de Stephen R. Palmer

Você investigou o uso de anotações java ORM em seu código ao criar seu diagrama de classes? O Hibernate geraria o banco de dados assim que o estágio de modelagem terminar. O diagrama é neste exemplo apenas um visualizador do código.

Referências a objetos ou ponteiros são semelhantes às chaves estrangeiras. É tão profundo quanto estou disposto a pensar sobre isso. :)

Na verdade, vou pensar mais fundo. Se você modelar seus objetos com duplicação de dados 0 e puder "consultá-los" e executar atualizações baseadas em conjunto, não haverá desconexão. Na verdade, você PODE fazer isso criando uma biblioteca de consumidor de objetos. A Microsoft já pensou nisso, mas foi na direção de tornar a sintaxe LINQ baseada em conjunto parte do C # em uma "biblioteca de consultas".