Object Oriented Design Tips

转载 2006年05月17日 15:34:00


Here is an assortment of tips to keep in mind when using object oriented design in embedded systems:

  1. Stay close to problem domain
  2. Object discovery vs. object invention
  3. Pick nouns or noun phrases as classes
  4. Method names should contain a verb
  5. Prefix adjectives when naming inheriting classes
  6. Do not add suffixes to class names
  7. Avoid one-to-one mapping from structured design
  8. Replace multiple get-set methods with operations
  9. Model classes that handle messages as state machines
  10. Use const whenever possible
  11. Restrict header file level dependency
  12. Don't reinvent the wheel; use STL

Stay close to problem domain

Design is a process of modeling the problem domain into programming constructs. Object oriented design simplifies the design process by maintaining a one-to-one mapping between problem domain objects and software objects. To succeed in object oriented design, keep your design as close as possible to problem domain objects. The interactions between your objects should mirror interactions between corresponding problem domain objects.

Problem domain objects is basically an object that can be found in the problem itself. For example, when developing a text editor real-world objects would be, Paragraph, Sentence, Word, ScrollBar, TextSelection etc. While developing a call processing module, the objects might be Call, Ringer, ToneDetector, Subscriber etc. 

Object discovery vs. object invention

The first step in object oriented analysis is to discover the objects that can be directly identified from the problem itself. In many cases objects can be identified  from the requirements. Objects discovered from the problem statement are extremely important. These objects will be the core objects in the design.

The next stage in object design is to "invent" objects. These objects are needed to "glue" together objects that have been identified during object discovery. Invented objects generally do not correspond to anything tangible in the problem domain. They are inventions of programmers to simplify design.

Consider the following statement from the requirements:

The circuit controller shall support digital and analog circuits. The circuit controller shall contain 32 DSPs. When the circuit controller receives a request to setup a circuit, it shall allocate a DSP to the circuit.

We discover the following objects from the requirement:

  • CircuitController
  • DigitalCircuit
  • AnalogCircuit
  • DSP

We invent the following objects based on our knowledge of the manager design pattern:

  • DSPManager: Manages the 32 DSPs on the circuit controller
  • CircuitManager: Manages the digital and analog circuits

We invent a Circuit base class for DigitalCircuit and AnalogCircuit by filtering properties that are common to DigitalCircuit and AnalogCircuit objects.

The relationship between the classes also follows from the requirement. CircuitController class contains DSPManager and CircuitManager classes. The CircuitManager contains an array of Circuit class pointers. The DSPManager contains an array of DSP objects.

Pick nouns or noun phrases as classes

Identifying objects is easy, they should always be nouns. As we have seen in the Circuit Controller example, we picked up nouns from the requirements as classes in our design. Even when you invent classes, keep in mind that they should be nouns. Abstract concepts don't qualify as object names. 

Naming the objects is extremely important in object oriented design. Chances are that if you name your object correctly, the designers and maintainers will assign it functionality that fits its name. Also note that, if you have trouble naming an object, you probably have the wrong object. At this point go back and look at the problem again and see if you can pick an alternative object.

Method names should contain verbs

In any language, actions performed by nouns are specified using verbs. Why should object oriented programming be any different? Thus make sure all the operation methods should contain verbs.

Thus the Circuit class we discussed earlier would have methods like:

  • Activate
  • Deactivate
  • Block
  • Unblock
  • ChangeStatus

Notice that the methods do not include Circuit in the name (ActivateCircuit, BlockCircuit etc.) as being methods of Circuit its clear that they refer to operations on Circuit.

Prefix adjectives when naming inheriting classes

This one is fairly obvious. When a class inherits from a base class, the name for the new class can be determined just by prefixing it with the appropriate adjective. For example, classes inheriting from Circuit are called AnalogCircuit and DigitalCircuit. Following this convention leads to class names that convey information about the classes inheritance. 

Do not add suffixes to class names

Do not add suffixes like Descriptor, ControlBlock, Agent to the class names. For example,  DigitalCircuit should not be called DigitalCircuitDescriptor or DigitalCircuitControlBlock. Such names are longer and do not convey the exact role of the class.

Avoid one-to-one mapping from structured design

Many developers moving from structured design just continue with structured design in C++. The classes developed correspond more to similar structured constructs they have used in the past. Similarity between C and C++ confuses developers. Make no mistake, object oriented programming is a completely different technique. The emphasis here is to keep the design process simple by minimizing the difference between the problem domain and software domain.

Replace multiple get-set methods with operations

Developers complain that after moving to object oriented programming, they spend considerable time writing mindless get and set methods. Here is a simple tip on reducing the get and set methods. Consider the code below:

Circuit Status (Multiple Get-Set)


The above code can be replaced by moving the field filling in the message to the Circuit class. This way you do not need to define a large number of get operations. Also, any changes in the CircuitInfo field would result only in changes to the Circuit class. CircuitManager would be transparent as it does not look into CircuitInfo.

Circuit Status (Single Operation)


Model classes that handle messages as state machines

Whenever you encounter a class that has to perform some level of message handling, its always better to model it as a state machine. We have discussed this in the article on hierarchical state machines.

Use const whenever possible

C++ provides powerful support for const methods and fields. const should be used in the following cases:

  • Methods that do not change the value of any variable in the class should be declared const methods.
  • If a function is supposed to just read information from a class, pass a const pointer or reference to this function. The called function would be restricted to calling const methods and using the classes fields only on the right side of an expression.

Proper and consistent use of const will help you catch several bugs at compile time. So start using const from day one of your project.  If const is not used extensively from the beginning of a project, it will be close to impossible to add it later.

Restrict header file level dependency

Complex software requires a careful header file management even when programming in C. When developers move to C++, header file management becomes even more complex and time consuming. Reduce header file dependency by effective use of forward declarations in header files. Sometimes to reduce header file dependency you might have to change member variables from values to pointers. This might also warrant  changing inline functions to out-of-line functions. Every time you use a #include make sure that you have an extremely good reason to do so.

For details refer to the header file include patterns article.

Don't reinvent the wheel; use STL

The C++ standard template library is extremely powerful. It can save countless hours of coding and testing of complex containers and queues. Details can be found in the STL design patterns  and STL design patterns II articles. 

[转]Object Oriented Design Principles

Who is Audience? This article is intended for those who have at least a basic idea of Object orient...
  • xiajian2010
  • xiajian2010
  • 2013年08月08日 21:29
  • 1628

★Object Oriented Design Tips

Object Oriented Design Tips(http://www.eventhelix.com/RealtimeMantra/Object%5FOriented/object_design...
  • wswms
  • wswms
  • 2006年05月29日 16:47
  • 654

Design Patterns Elements of Reusable Object-Oriented Software(一)Introduction(介绍)

1.Introduction(介绍) Designing object-oriented software is hard,and designing reusable object-oriented...
  • liuzuyi200
  • liuzuyi200
  • 2013年07月17日 10:29
  • 1369

Object-Oriented Analysis and Design Using UML 翻译与学习 (目录)

Object-Oriented Analysis and Design Using UML 面向对象分析与使用UML设计   最近找了本书《Object-Oriented Analysis and ...
  • CB44606
  • CB44606
  • 2016年06月07日 22:23
  • 3609

面向接口设计(Interface Oriented Design)

         我在网上搜索这个概念的时候,发现在中国还很少有此类文章,外国有一本同名书籍出版,但是无缘拜读。所以这个概念基本是我自己杜撰出来的,只是网上也有同名而已。       先说说,什么是接...
  • xiammy
  • xiammy
  • 2006年11月25日 00:05
  • 3733

OOD(object oriented design)

design pattern在我们的代码中经常会出现, 帮助我们设计以及说明我们的设计意图。它们是前人的宝贵经验的总结, 也是我们设计结构时候的重要依据。在接下来的几篇文章里, 我们重点讨论一下5种设...
  • baijiwei
  • baijiwei
  • 2017年12月17日 15:55
  • 41

Object Oriented Design Pricinple

What is object oriented design? What is it all about? What are it's benefits? What are it's costs? I...
  • metasearch
  • metasearch
  • 2012年03月30日 17:27
  • 435

面向对象编程(Object Oriented Programming)概念总结及延伸(一)

1.介绍    笔者的梦想是成为一个架构师,但是要成为一个合格的架构师是相当不易的,它既需要丰富的项目经验也需要不断地吸取新的知识,而且在这过程中我们也要不断巩固基础知识。我也注意到了,现在主流的文章...
  • csdbfans
  • csdbfans
  • 2010年11月29日 23:35
  • 795

Object Oriented Design面向对象设计

      面向对象的设计 ...
  • lwhlau
  • lwhlau
  • 2007年04月05日 14:27
  • 439

Object Oriented Design Parttern

Design PatternsCreational Design Patterns: Click to zoomSingleton - Ensure that only one instan...
  • lk5423968
  • lk5423968
  • 2010年10月26日 11:27
  • 395
您举报文章:Object Oriented Design Tips