What are the important rules in Object Model Design

Question

Hi

We are developing an extension (in C# .NET env.) for a GIS application, which will has predefined types for modeling the real world objects, start from GenericObject, and goes to more specific types like Pipe and Road with their detailed properties and methods like BottomOfPipe, Diameter and so on.

Surely, there will be an Object Model, Interfaces, Inheritance and lots of other essential parts in the TypeLibrary, and by now we fixed some of them. But as you may know, designing an Object Model is a very ambiguous work, and (I as much as I know), can be done in many different ways and many different results and weaknesses.

Is there any distinct rules in designing O.M.: the Hierarchy, the way of defining Interfaces, abstract and coclasses enums?

Any suggestion, reference or practice?

Answer 1

Check out the "principles" of Object oriented design. These have guidelines for all the questions you ask.

References:

• "Object oriented software construction" by Robert Martin
• http://www.objectmentor.com/resources/publishedArticles.html

Checkout the "Design Principles" articles at the above site. They are the best references available.

Answer 2

A couple of good ones:

SOLID

Single responsibility principle
Open/closed principle
Liskoff substitution principle
Interface segregation principle
Dependency inversion principle

More information and more principles here: http://mmiika.wordpress.com/oo-design-principles/

Answer 3

I suggest you to read the following series of blog posts for Brad Adams, FrameWork Design Guidelines

Answer 4

"BottomOfPipe"? Is that another way of saying the depth of the Pipe below the Road?

Any kind of design is difficult and can be done different ways. There are no guarantees that your design will work when you create it.

The advantage that people who design ball bearings and such have is many more years of experience and data to determine what works and what does not. Software doesn't have as much time or hard data.

Here's some advice:

1. Inheritance means IS-A. If that doesn't hold, don't use inheritance.
2. A deep hierarchy is probably a sign of trouble.
3. From Scott Meyers: Make non-leaf classes interfaces or abstract.
4. Prefer composition to inheritance.

Answer 5

Check out Domain-Driven Design: Tackling Complexity in the Heart of Software. I think it will answer your questions.

Answer 6

Thanks all I'm working on your answers Thanks again

Answer 7

what they said, plus it looks like you are modeling real-world entities, so:

• restrict your object model to exactly match the real-world entities.

You can use inheritance and components to reduce the code/model, but only in ways that make sense with the underlying domain.

For example, a Pipe class with a Diameter property would make sense, while a DiameterizedObject class (with a Diameter property) with a GeometryType property of GeometryType.Pipe would not. Both models could be made to work, but the former clearly corresponds to the problem domain, while the latter implements an artificial (non-real-world) perspective.

One additional clue: you know you've got the model right when you find yourself discovering new features in the code that you didn't plan from the start - they just 'naturally' fall out of the model. For example, your model may have Pipe and Junction classes (as connectivity adapters) sufficient to solve the immediate problem of (say) joining different-diameter pipes to each other and calculating flow rates, maximum pressures, and structural integrity. You later realize that since you modeled the structural and connectivity properties of the Pipes and Junctions accurately (within the requirements of the domain) you can also create a JungleGym object from connected pipes and correctly calculate how much structural load it will bear.

This is an extreme example, but it should get the point across: correct object models support extension and often manifest beneficial unexpected properties and features (not bugs!).

Answer 8

The Liskov Substitution Principle, often expressed in terms of "is-a". Many examples of OOP would be better off making use of "has-a" (in c++ private inheritance or explicit composition) rather than public inheritance ("is-a")

Getting Inheritance right is hard. Doing so with interfaces (pure virtual classes) is often easier than for base/sub classes