ood.txt

ears-0.32, linux下有用的语音信号处理工具包

			  Principles of OOD

(author is Robert Martin, check his page on www://www.oma.com/ )

--------------------------------------------------------------------
   1. Software entities (classes, modules, etc) should be open for
      extension, but closed for modification.  (The open/closed
      principle -- Bertrand Meyer)
--------------------------------------------------------------------

The open/closed principle is the single most important guide for an
object oriented designer.   Designing modules whose behavior can be
modified without making source code modifications to that module is
what yields the benefits of OOD.

Consider the following:

class Shape                 {public: virtual void Draw() const = 0;};
class Square : public Shape {public: virtual void Draw() const;};
class Circle : public Shape {public: virtual void Draw() const;};

typedef Shape *ShapePointer;

void DrawAllShapes(ShapePointer list[], int n)
{
  for (int i=0; i<n; i++)
    list[i]->Draw();
}

Notice that the function 'DrawAllShapes' need not be modified when new
kinds of shapes are added to the Shape hierarchy.  In fact, the
function need not even be recompiled.

Yet, even though I don't make changes to the module, I *can* change
its behavior.  Although the function currently only draws circles and
squares, I can enhance it to draw any other shape at all, so long as
that shape is represented by an object that derives from the class
Shape.

So, I can extend the behavior of the module 'DrawAllShapes', without
modifying it at all.

Now, consider how this would have been done in a language like C.

enum ShapeType {circle, square};
struct Shape  {ShapeType itsType;};
struct Circle {ShapeType itsType; double itsRadius; Point itsCenter;};
struct Square {SahepType itsType; double itsSide; Point itsTopLeft;};

void DrawSquare(struct Square*);
void DrawCircle(struct Circle*);

typedef struct Shape *ShapePointer;

void DrawAllShapes(ShapePointer list[], int n)
{
  int i;
  for (i=0; i<n; i++)
  {
    struct Shape* s = list[i];
    switch (s->itsType)
    {
    case square:
      DrawSquare((struct Square*)s);
    break;

    case circle:
      DrawCircle((struct Circle*)s);
    break;
    }
  }
}

It should be very clear that the 'DrawAllShapes' function, as written
in C, cannot be extended without direct modification.  If I need to
create a new shape, such as a Triangle, I must modify the
'DrawAllShapes' function.

This, by itself, would not be too bad.  However, in a complex
application the switch/case statement above is repeated over and over
again for every kind of operation that can be performed on a shape.
These statements are difficult to find, and it is easy to make
mistakes when modifying them.

Worse, every module that contains such a switch/case statement retains
a dependency upon every possible shape that can be drawn, thus,
whenever one of the shapes is modified in any way, the modules all
need recompilation, and possibly modification.

A major factor in software maintenance is the fact that for every
change that is made, there is a risk that bugs will be introduced.
This wreaks havoc with managers and users because old features that
used to work just fine will sometimes break when a new, and apparently
unrelated, feature is added.

However, when the majority of modules in an application conform to the
open/closed principle, then new features can be added to the
application by *adding new code* rather than by *changing working
code*.  Thus, the working code is not exposed to breakage.  This
creates a significant amount of isolation between features, and allows
for much easier maintenance.

--------------------------------------------------------------------
   2. Derived classes must be usable through the base class interface
      without the need for the user to know the difference.  (The
      Liskov Substitution Principle)
--------------------------------------------------------------------

This rule is a logical extension of the open/closed principle.
Consider function F that uses type T.  Given S a subtype of T, F
should be able to use objects of type S without knowing it.  In fact,
any subtype of T should be substitutable as an argument of F.  If this
were not true, then F would have to have tests to determine which of
the various subtypes it was using.  And this breaks the open/closed
principle

For example:  Consider the problem of the Square and the Rectangle.
Mathematically a Square *is* a Rectangle.  This tempts us to invoke
inheritance between them:

        class Rectangle
        {
          public:
            Rectangle(const Point& tl, double h, double w)
            : itsTopLeftPoint(tl)
            , itsHeight(h)
            , itsWidth(w)
            {}

            virtual void SetHeight(double h) {itsHeight=h;}
            virtual void SetWidth(double w)  {itsWidth=w;}

            virtual double GetWidth()  const {return itsWidth;}
            virtual double GetHeight() const {return itsHeight;}

          private:
            Point itsTopLeftPoint;
            double itsHeight;
            double itsWidth;
        };

        class Square : public Rectangle
        {
          public:
            Square(const Point& tl, double s)
            : Rectangle(tl, s, s)
            {}

            virtual void SetWidth(double w)
            {
              Rectangle::SetWidth(w);
              Rectangle::SetHeight(w);
            }

            virtual void SetHeight(double h)
            {
              Rectangle::SetWidth(h);
              Rectangle::SetHeight(h);
            }
        };

In the example above, Square inherits from Rectangle, but the
functions of Square are overridden to enforce that the height and
width of the Rectangle are always the same.

Now, consider a function which takes a Rectangle as an argument, and
adjusts its width so that it has an aspect ratio of 1/2.  i.e. the
width is half the height.

        void HalfAspect(Rectangle& r)
        {
           r.SetWidth(r.GetHeight()/2);
        }

This function fails, rather dismally, if a Square is passed into it as
follows:

        Square s;
        HalfAspect(s); // this just shrinks both sides by 2

Since a user of Rectangle can malfunction when passed a Square, Square
is not substitutable for Rectangle.  To make a general fix, we would
have to add code to HalfAspect to test the incoming Rectangle to see
if it was a Square:

        void HalfAspect(Rectangle& r) throw(BadType)
        {
           if (typeid(r) == typeid(Square))
               throw BadType;

           r.SetWidth(r.GetHeight()/2);
        }

And this creates a dependency upon Square.  Moreover, every time a new
unsubstitutable derivative of Rectangle is created, a new test must be
added to all functions that would malfunction.   This violates the
open/closed principle.

--------------------------------------------------------------------
   3. Details should depend upon abstractions.  Abstractions should
      not depend upon details.  (Principle of Dependency Inversion)
--------------------------------------------------------------------

This is the direction that all dependencies should take in an object
oriented program.  All high level functions and data structures should
be utterly independent of low level functions and data structures.

Consider a program that controls a home furnace.

    Furnace()
    {
        while(;;)
        {
            while (ReadTemp() > theMinTemp)
                wait(1);

            StartFurnace();

            while (ReadTemp() < theMaxTemp)
                wait(1);

            StopFurnace();
        }
    }

This is clearly a simple minded algorithm, but it will serve to
demonstrate our point.  Notice that this algorithm will apply to any
furnace at all.  Thus this high level algorithm is an abstraction, it
is independent of the type of furnace we have.

However, most of the time, programmers will take a high level policy
and code it in terms of the low level details.

    #define THERMOMETER 0x86
    #define FURNACE     0x87
    #define FURNACE_ON  0x01
    #define FURNACE_OFF 0x00

    Furnace()
    {
        while(;;)
        {
            while (in(THERMOMETER) > theMinTemp)
                wait(1);

            out(FURNACE, FURNACE_ON);

            while (in(THERMOMETER) < theMaxTemp)
                wait(1);

            out(FURNACE, FURNACE_OFF);
        }
    }

It should be pretty clear that this high level function is polluted by
the details of the actual furnace controller.  In fact, the
abstraction depends upon the details.

It should also be clear that this function cannot be reused with a
different kind of furnace.  When abstractions depend upon details, the
abstractions cannot be reused.

We might think that we can improve this by employing structured design
as follows:

    #include "furnace.h"

    Furnace()
    {
        while(;;)
        {
            while (ReadTemp() > theMinTemp)
                wait(1);

            StartFurnace();

            while (ReadTemp() < theMaxTemp)
                wait(1);

            StopFurnace();
        }
    }

    --------------furnace.h------------

    double ReadTemp();
    void StartFurnace();
    void StopFurnace();