In database programming there's a technique called "normalization" that you do to data you want to store.

Has anyone tried to apply this concept to object design? How did you? How did it work out?

Edit: To expand/clarify, database normalization is more than a set of principles to reduce redundancy. There's actually steps and stages you go through and at least moderately objective measures that tell you which stage you are in. Object design has its own principles, and there's the concept of smell, but is there any way to do something similar that would tell you that you're in XX-form0,1,2...etc...and methods to move to the next most "normalized" level?

  • 2
    ...You mean have we tried not having multiple redundant variables in our classes, and not having multiple redundant classes in our projects? Would that even work? Commented Jun 16, 2011 at 19:56
  • 2
    @Steven A. Lowe: Where were you five years ago when I was deciding on a topic of my master thesis? ;)
    – user8685
    Commented Jun 16, 2011 at 19:58
  • I've never tried it (which is why I'm answering as a comment) but I'm guessing you could do this with a cache of shared data, pointers from objects to the cached shared data, and some sort of dependency injection mechanism to point the pointers of the instances to the shared data... Commented Jun 16, 2011 at 20:06
  • A very interesting question I find it.
    – user8685
    Commented Jun 16, 2011 at 20:07
  • 5
    I think Refactoring pretty much covers that both for OOP and other programming methodologies.
    – JohnFx
    Commented Jun 16, 2011 at 22:28

6 Answers 6


While some of the underlying tensions that drive database normalization are not present in an OO system, some of them are. These have given rise to OO design patterns and principles that are in some ways analogous to normalization, at least inasmuch as OO systems are analogous to relational databases. For example:

In other words, has anyone tried to apply database normalization techniques to OOP? No, because OOP already has solutions for the shared problems that normalization solves for relational databases.

  • +1 Much better than what I was trying to write!
    – Michael K
    Commented Jun 16, 2011 at 20:06
  • Those are principles, not techniques though. How would you use those principles to "normalize" an object design? Commented Jun 16, 2011 at 20:09
  • 4
    Database normalization is a principle as well. In both cases, there are patterns (or techniques) that describe how to make decisions regarding these principles. Look into Martin Fowler's books on refactoring and Kent Beck's books on patterns, for instance. The difference is that database design is a smaller, less complex domain that is easier to quantify and turn into a simple set of rules. Commented Jun 16, 2011 at 20:15
  • 5
    @Crazy Eddie: How do you do it with a relational database? You look for instances where a principal is violated and correct it. If you see a class with three jobs, you rewrite it as three classes. If you are looking for a verb like "normalize" maybe its "refactor" although that is not quite as specific it is inclusive.
    – Jeremy
    Commented Jun 16, 2011 at 20:18
  • 1
    @Rein: database design is neither smaller nor less complex than OOP, but it had one huge advantage: it began with a solid theoretical foundation and mathematical model. OOP has evolved a lot of heuristics, but still has no complete formalism. Commented Jul 4, 2011 at 16:24

Yes, Yes I Have

I've kept quiet on this topic for a long time; it's time speak out.

  • Has anyone tried to apply this concept to object design?

Yes. I've been working on formalizing object normalization (and hence the underlying object-oriented theory) for over 20 years.

  • How did you?

By realizing that data and code are interchangeable, at least in theory. This means that the principles of normalization and the relational operations can apply to code as well as data.

  • How did it work out?

It worked out pretty well so far - I believe the insights gained have been the "secret weapons" of my design, analysis, and refactoring abilities.

I haven't said anything about it publicly before this because I figured that eventually I would have time to finish the research - and produce the implied tools - myself.

But I've come to the conclusion that with everything else going on in my life that is more important, more fun, and/or more profitable, I am not going to have the time to finish the research myself. Ever. There's also the significant possibility that I simply do not have the requisite CS theoretical foundation to complete the work alone.

I have inquired at the local university about sponsoring a PhD candidate or two if they'd like to take up the cause, but alas our local university does not teach an adequate foundation in programming language semantics.

There has been some interesting research in this area, but all of it - that I'm aware of - has fallen short of the mark. Either it assumes incorrectly that because normalization comes from a relational background it does not apply to object-oriented models, or it assumes that normalization only applies to the data defined by objects. There are some very interesting near-miss projects however...

The really interesting stuff happens when you apply normalization to the code - which I would argue is the foundation of all refactoring.

So now I'm thinking that the best thing to do is to get the word out, perhaps by asking to speak at DevDays 2011 in DC, and find out if there is a community as excited by this stuff as I am.

Here's a sneak peek: Normalization is the process of making something minimal and non-redundant. The Don't Repeat Yourself (DRY) principle of object-oriented programming is therefore a clear manifestation of the goals of normalization. I believe I can show that all of the well-known object-oriented design/programming/refactoring principles are the logical consequence of object normalization. I think I can also show that there are more interesting things that can be done with systems in Object Normal Form (ONF) than just refactoring.

  • 1
    Any more substantial documents?
    – user8709
    Commented Jul 3, 2011 at 4:18
  • 4
    PUBLISH! (please?) (pretty please?) If you need any help getting docs in order, etc. contact me.
    – AJ01
    Commented Jul 12, 2011 at 9:12
  • 1
    @ChrisCirefice: be happy to, shoot me an email at [email protected] Commented May 27, 2014 at 17:32
  • 1
    @ChrisCirefice: just FYI, PhD candidate moved on to a different university; project on back-burner again (but I'm writing a book on DDD) Commented Oct 11, 2016 at 21:06
  • 1
    Hi @StevenA.Lowe I am really interested in your research. I've found a rather short paper encrypted.google.com/… do you have any comment on this? BTW, maybe you can illustrate your idea a little more by writing a blog post first? Thanks.
    – Wei Qiu
    Commented Jun 2, 2017 at 14:33

This started as a comment on Rein Henrichs excellent answer, but got too long...

Normalization applies to relational data. It is used to avoid duplication, which makes it easier to ensure data integrity since each datum is stored in only one place. You normalize a database by finding violations of a normalized form and correcting them.

Object-Oriented Programming applies to operations on data. It is meant to group ways of manipulating data together. You could apply similiar techniques to classes to eliminate duplicate methods, perhaps by looking at what data the operation manipulates or depends on. For example, 1NF in a OO perspective would not have any duplicate operations within a class. 3NF might correspond with a good inheritance structure in which commonly used code is in a superclass. I'm sure you could find a place to fit dependency injection in there too. You reach a better design (although nothing like normal forms has yet been discovered) by finding violations of good design principles and refactoring.

There aren't really any algorithmic methods to reach a good design in either world. As Rein Hendrichs points out, there are many principles that can identify potential issues (aka. code smells). Design patterns and best practices are some of the ways people have tried to address them. Test-driven development attempts to find them early by exercising the code as it will be externally. Just as in database development, the best solution is found with experience and analysis.

  • 2
    My view is that principles are a statement about the ideal way to resolve a set of tensions. Patterns are a heuristic for applying a principle. IOW principles are a statement about the structure of the problem space and patterns are rules for transforming them into a solution space. But I'm sort of a math nut, so I think weird :) Commented Jun 16, 2011 at 21:14

A very good approach to design business model objects that is similar to normalization is UML Modeling in Color.

It is a design strategy found by Peter Coad that helps to abstract the business model objects.

Unfortunately the book - Java Modeling In Color With UML: Enterprise Components and Process - is sold out and you can only buy used ones.

There is a couple of articles over the internet about this technique.

If you are familiar with relational design you will find UML Modeling in Color useful to guide you :


Have you investigated to use ORM java annotations in your code while creating your class diagram ? Hibernate would generate the database once the modelling stage is finish. The diagram is in this example only a viewer of the code.


Object references or pointers are similar to foreign keys. That's as deep as I'm willing to think on this. :)

Actually I'll think deeper. If you model your objects with 0 data duplication and could "query" your objects and perform set based updates on them there would be no disconnect. In fact you CAN do this by making an object consumer library. Microsoft has already though of this but went the direction of making set-based LINQ syntax part of C# over a "query library".

  • Yes. You want to apply Normalize System Theory to your platform. NST, build from the Lehman's Laws (70s-80s) allows you to scale your software infinity with linear growth in complexity. Hence (near) flat cost to continually add new functionality to your software. Most tiered software platforms have this pattern (real tiered, not marketing tiered)
    – Chris
    Commented Oct 23, 2021 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.