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

You should look at UML, which is an entire process given to OOD.

I'd recommend getting a book (or a couple), because the theory is quite large, most people pick and choose the techniques most appropriate for the project at hand.

Answer 2

Check the results of this. Learn from each question.

Answer 3

Start reading about design patters, from say Martin Fowler. :)

They are the most practical use of OOP.

Answer 4

The book "Design Patterns" is your next step.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612

But, you don't have to use an OO approach to everything. Don't be religious about it. If a more procedural approach feels more straitforward, then go with that. People new to OO tend to overdue it for a while.

Answer 5

I really liked Head First Design Patterns, which is very approachable, and the excellent Object oriented Design Heuristics by Arthur J. Riel

Answer 6

If you're used to building normalized databases, then Object Oriented design should come naturally to you. Your class structures will end up looking a lot like your data structure, with the obvious exception that association tables turn into lists and lookup tables turn into enums within your classes.

All together, I'd say you're a lot better off coming into OO design with a background in Relational Databases than you would be going the other direction.

Answer 7

If you want to really get to grips with O-O, go play with Smalltalk. ST is a pure OO language, and quite in-your-face about it. Once you get over the paradigm hump you've learned OO as you can't really do Smalltalk without it. This is how I first learned OO.

Answer 8

I am guess you mean OO in the database world.

Object-oriented databases which store objects never did really catch one so you are currently looking mapping objects to relational database. ORM or Object-relational mapping is the term used to describe the software that does this mapping. Ideally this gives you the best of both worlds where developers can internact with the objects and in the database everything is stored in relational tables where standard tuning can take place.

Answer 9

Go for Object Thinking by David West. An interesting read..
You're from the dark side though.. as per the book;) Database thinking has been the curse of OO programmers all over. They're opposite ends of a spectrum. For instance

• Database thinking values the data attribues over everything else.. normalization and creating types based on how they fit into the DB Schema OR the ER diagram.. OO thinking creates types based on behavior and collaboration and does not recognize the data attributes as all important.
• Databases come from the scientific people who value formalization and method over everything else. OO comes from the people who use heuristics and rules of thumb and value individuality and social interaction over a hard and fast process.

The point being a COBOL programmer can write COBOL programs even after moving onto a OO Language. Check out any book like Thinking in Java for the first section which invariably details out the tenets of OO (Apprentice).. Follow it up with Object Thinking (journeyman) and in due time.. a master.

Answer 10

This site lists 101 title... design patterns, refactoring and other... Have a look at it.. It will be a good starting point...

Answer 11

I think Agile Software Development, Principles, Patterns, and Practices is quite good.

It provides a lot of in-depth disccusion of OO principles listed here:

• The principles of Object Oriented Design and Dependency Management
• SRP — The Single Responsibility Principle
• OCP — The Open Closed Principle
• LSP — The Liskov Substitution Principle
• DIP — The Dependency Inversion Principle
• ISP — The Interface Segregation Principle
• REP — The Reuse Release Equivalency Principle
• CCP — The Common Closure Principle
• CRP — The Common Reuse Principle
• ADP — The Acyclic Dependencies Principle
• SDP — The Stable Dependencies Principle
• SAP — The Stable Abstractions Principle

Answer 12

Model your objects by keeping real world objects in mind.

We are currently developing automation software for machines. One of those machines has two load ports for feeding it raw material, while all others have only one. In all modules so far, we had the information of the ports (current settings, lot number currently assigned to it etc) as members in the class representing the machine.

We decided to create a new class that holds the information of the ports, and add two LoadPort members to this MachineXY class. If we had thought about it before, we would have done the same for all those single port machines...

Answer 13

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.