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 dee

Answer 1

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 2

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 3

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.

Answer 4

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 5

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 6

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.