Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
6  
If any PhDs want to take this on as a thesis topic, my company may be willing to sponsor your work. –  Steven A. Lowe Jun 16 '11 at 19:56
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? –  Satanicpuppy Jun 16 '11 at 19:56
1  
@Steven A. Lowe: Where were you five years ago when I was deciding on a topic of my master thesis? ;) –  user8685 Jun 16 '11 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... –  FrustratedWithFormsDesigner Jun 16 '11 at 20:06
5  
I think Refactoring pretty much covers that both for OOP and other programming methodologies. –  JohnFx Jun 16 '11 at 22:28
show 4 more comments

6 Answers

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.

share|improve this answer
    
+1 Much better than what I was trying to write! –  Michael K Jun 16 '11 at 20:06
    
Those are principles, not techniques though. How would you use those principles to "normalize" an object design? –  Crazy Eddie Jun 16 '11 at 20:09
3  
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. –  Rein Henrichs Jun 16 '11 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 Jun 16 '11 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. –  Steven A. Lowe Jul 4 '11 at 16:24
show 1 more comment

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.

share|improve this answer
    
Any more substantial documents? –  Steve314 Jul 3 '11 at 4:18
    
@Steve314: no published papers, if that's what you mean. Didn't want to publish until the theory was 'complete', and of course never had the time to complete the theory! –  Steven A. Lowe Jul 3 '11 at 4:45
    
Why don´t you publish your thoughts / research about the subject of this answer in your book site? (BTW: I'd write OM1 and OM2 as the first two small chapters of OM3, and speak to an expert OOP programmer: that would make it much easier for me to write the book) –  Ando Jul 3 '11 at 9:21
    
@Andrea that's the plan, sort of - too many irons in the fire right now to be certain of the outcome. But yes was definitely thinking that ONF would be the focus of OM3. Or maybe OM4 ;-) –  Steven A. Lowe Jul 3 '11 at 21:40
2  
PUBLISH! (please?) (pretty please?) If you need any help getting docs in order, etc. contact me. –  AJ01 Jul 12 '11 at 9:12
show 3 more comments

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.

share|improve this answer
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 :) –  Rein Henrichs Jun 16 '11 at 21:14
add comment

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 :

share|improve this answer
add comment

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.

share|improve this answer
add comment

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".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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