Database Guy Asks: Object-Oriented Design Theory?

Question

I've worked with designing databases for a loooong time, and these days I'm working in C# too. OO makes sense to me, but I don't feel that I have a good grounding in the deep theory of OO design.

In database land, there's a lot of theory around how to design the structure of a database, the main notion being normalisation. Normalisation directly steers the structure of a database and to some extent dictates how to arrange entities in a database.

Are there any similar concepts behind how to design the structure of an Object-Oriented program?

What I'm reaching for is one or more underlying theoretical principles which naturally guide the developer into the "correct" design for the solution to a given problem.

Where can I look to find out more?
Is there a go-to work I should read?

Update:

Thanks to everyone for their answers. What I'm reading seems to say that there is no "Grand Theory of OO Design", but there are a bunch of important principles - which are largely exemplified by design patterns.

Thanks again for your answers :)

Answer 1

Be careful some of the design patterns literature.

There are are several broad species of class definitions. Classes for persistent objects (which are like rows in relational tables) and collections (which are like the tables themselves) are one thing.

Some of the "Gang of Four" design patterns are more applicable to active, application objects, and less applicable to persistent objects. While you wrestle through something like Abstract Factory, you'll be missing some key points of OO design as it applies to persistent objects.

The Object Mentor What is Object-Oriented Design? page has mich of you really need to know to transition from relational design to OO design.

Normalization, BTW, isn't a blanket design principle that always applies to relational databases. Normalization applies when you have update transactions, to prevent update anomalies. It's a hack because relational databases are passive things; you either have to add processing (like methods in a class) or you have to pass a bunch of rules (normalization). In the data warehouse world, where updates are rare (or non-existent) that standard normalization rules aren't as relevant.

Consequently, there's no "normalize like this" for object data models.

In OO Design, perhaps the most important rule for designing persistent objects is the Single Responsibility Principle.

If you design your classes to have good fidelity to real-world objects, and you allocate responsibilities to those classes in a very focused way, you'll be happy with your object model. You'll be able to map it to a relational database with relatively few complexities.

Turns out, that when you look at things from a responsibility point of view, you find that 2NF and 3NF rules fit with sound responsibility assignment. Unique keys still matter. And derived data becomes the responsibility of a method function, not a persistent attribute.