ood.txt

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

    -----------------furnace.c-------------
    #include "furnace.h"
    #define THERMOMETER 0x86
    #define FURNACE     0x87
    #define FURNACE_ON  0x01
    #define FURNACE_OFF 0x00

    double ReadTemp()     {return in(THERMOMETER);}
    void   StartFurnace() {out(FURNACE, FURNACE_ON);}
    void   StopFurnace()  {out(FURNACE, FURNACE_OFF);}

However, while this does break the direct dependency of the Furnace
function upon the details, there is still a one to one binding from
the name 'StartFurnace' to the function implemented in "furnace.h".
Thus, although we can some reusability by recoding "furnace.c", we
cannot gain reusability in the same program or application.

However, consider the following object oriented design.

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

    class Furnace
    {
      public:
        virtual void Start() = 0;
        virtual void Stop() = 0;
    };

    ---------thermometer.h----------

    class Thermometer
    {
      public:
        virtual double Read() = 0;
    };

    ------------ regulator.h ------------
    class Furnace;
    class Thermometer;

    class Regulator
    {
      public:
        Regulator(Furnace& f, Thermometer& t);
        void Regulate(double minTemp, double maxTemp);
      private:
        Furnace& itsFurnace;
        Thermometer& itsThermometer;
    };

    ---------------- regulator.cc ------------
    #include "regulator.h"
    #include "furnace.h"
    #include "thermometer.h"

    Regulator::Regulator(Furnace& f, Thermometer& t)
    : itsFurnace(f)
    , itsThermometer(t)
    {}

    void Regulator::Regulate(double minTemp, double maxTemp)
    {
        while(;;)
        {
            while (itsThermometer.Read() > theMinTemp)
                wait(1);

            itsFurnace.Start();

            while (itsThermometer.Read() < theMaxTemp)
                wait(1);

            itsFurnace.Stop();
        }
    }

    -------------------detailedFurnace.h---------------------
    #include "furnace.h"
    class DetailedFurnace : public Furnace
    {
      public:
        virtual void Stop();
        virtual void Start();
    };

    -------------------detailedFurnace.cc-------------------
    #define FURNACE     0x87
    #define FURNACE_ON  0x01
    #define FURNACE_OFF 0x00

    void   DetailedFurnace::Start() {out(FURNACE, FURNACE_ON);}
    void   DetailedFurnace::Stop()  {out(FURNACE, FURNACE_OFF);}

    -----------detailedThermometer.h --------------

    class DetailedThermometer : public Thermometer
    {
      public:
        virtual double Read();
    };

    ------------detailedThermometer.cc-------------

    #define THERMOMETER 0x86

    double DetailedThermometer::Read() {return in(THERMOMETER);}
    -------------------------------------------------------------

Notice that now the high level algorithm depends only upon abstract
classes.  Notice also that the details depend only upon the
abstractions.  Notice that the Regulator class can be reused with any
derivative of a Furnace and a Thermometer.  Morever, any application
can have many instance of Regulators, Thermometers, and Furnaces.
Thus, we could reuse this algorithm in, say, an application that
controls the reaction temperature of many different vessels....

Notice also that there is much more code in the OO version.  It takes
code to invert dependencies.  This is the price we pay for the reusability
and maintainability that dependency inversion affords.

--------------------------------------------------------------------
   4. The granule of reuse is the same as the granule of release.
      Only components that are released through a tracking system can
      be effectively reused.
--------------------------------------------------------------------

Reuse does not come automatically.  One cannot simply write a class
and claim that it is reusable.  First, a reusable class probably has
several classes that it collaborates with.  Thus the class is not
reusable in isolation, it must be reused in conjunction with other
classes.  Second, reusers do not want the classes that they are
reusing to change out from under them.  So they will require some kind
of release tracking system to be put into place.

It should be stated at this point that "code copying" is an inferior
form of code reuse.  Code copying puts the burden of maintenance upon
the reuser, not upon the author.  In such cases, the only thing that
is being reused is the initial design of the code.  Yet we all know
that initial design is worth a small percentage of the total effort
through the lifecycle of a project.  Thus we want reusable code to be
maintained by the author, or by a common maintainer.  We want all the
reusers to benefit from the single source of maintenance.

In order to achieve reuse of this kind, the reusable software must be
put into a form that the reusers can manage.  Specifically, this means
that it must be segregated into "chunks" which are relatively
independent of each other, and given version numbers so that the
reusers can track which version of a chunk they are currently using.

The chunks must be small enough so that reusers can pick and choose
the software that they want to reuse.  Reuse is not worth much when it
is an all-or-nothing proposition.

When changes are made to these released "chunks", new version numbers
must be assigned, and notification must be given to all reusers.
Reusers will then decide if they wish to use the new release
immediately, delay such use until their software can be made
compatible, or reject such use and take over maintenance of the
previous version themselves.

In the absence of a release strategy and version numbering scheme,
reuse of commonly maintained software modules is extremely difficult,
if not impossible.  Thus, we say that "the granule of reuse is the
same as the granule of release."

Now this has implications for the way that object oriented programs
should be structured.   One such structuring mechanism is employed by
Booch.  He organizes a group of cohesive classes into an entity called
a class category.  Class categories can be used as the granule of
release, and therefore the granule of reuse.

--------------------------------------------------------------------
   5. Classes within a released component should share common closure.
      That is, if one needs to be changed, they all are likely to need
      to be changed.  What affects one, affects all.  (The principle
      of Common Closure).
--------------------------------------------------------------------

Released components are the targets for dependencies.  In fact, the
reason that they are "released" is to limit the affect of changes upon
the users of the component.  This implies that releases should not
occur often, and that they should occur in isolation where possible.

The worst case scenario is when a change to the system causes
modification of all the released components, such that they all need
to be re-released.  When changes occur, we want those changes to
affect the smallest possible number of released components.

In OOD, the released coponent is the "category".  And the principle we
are discussing is the principle of "Common Closure within Categories."
This priciple is the first and most important of the three rules for
category cohesion.  A category is cohesive, if the classes within it
are all closed to the same kinds of modifications.

The open closed principle states that a class should be open for
extension but closed for modification.  This is an ideal that cannot
be completely achieved.  Regardless of the design of a class, there
will always exist some kind of change that will force the class to be
opened.  However, do not have to protect ourselves from every kind of
modification.  We can anticipate the kinds of modifications that are
likely to be requested, and protect ourselves from those.

Thus, we design our classes to be closed to the most likely kinds of
changes that we can forsee.  This means that the closure of a class is
partial, and specifically targeted at certain kinds of changes.

The principle of common closure states that, given a particular kind
of change, either all of the classes within a category are closed to
it, or they are all open to it.

When this principle can be achieved, changes do not propogate through
the system.  Rather they focus upon one, or a few categories, while
the rest of the categories remain unaffected.  This greatly lessens
the number of categories that are affected by a change, and reduces
the frequency with which categories must be released.

--------------------------------------------------------------------
   6. Classes within a released componen should be reused together.
      That is, it is impossible to separate the components from each
      other in order to reuse less than the total.
--------------------------------------------------------------------

When a user decides to reuse a component, he creates a dependency upon
the whole component.  When a new release of that component is created, the
user must reintroduce that new release into his existing applications.
Therefore, the user will want each component to be as focused as
possible.  If the component contains classes which the user does not
make use of, then the user may be placed in the position of accepting
the burden of a new release which does not affect any of the classes
within the component that he is using.   Thus, comoponents should be
kept relatively narrow.  If the user uses one of the classes in the
component, then it should be extremely likely that he should reuse
all the other classes in the component.

Generally, this kind of focus is enforced by the relationships that
exist between classes that are reused together.  Those relatioships
represent dependencies that force the user to bring along all the
classes within a component.

It is important that dependencies that are associated with reuse be
encapsulated within a single component where possible.  If the reuse
of a particular class within a component forces the reuse of other
components, then the user has a bigger reuse burden.

--------------------------------------------------------------------
   7. The dependency structure for released components must be a DAG.
      There can be no cycles.
--------------------------------------------------------------------

Consider an application that is divided up into many different class
categories.  A given class category can be released, only when it is
compatible with those categories that it depends upon.

This ability to release an application in peices facilitates
development.  If applications cannot be released in pieces, then the
developers interfere with each other as they are making changes to
their code.

The typical horror story is of an engineer who works all day to get
his stuff working.  He goes home a night satisfied.  However upon
returning the next morning, he is dismayed to find that his stuff no
longer works.  The reason:  Sombody stayed later than he did and
changed something that he depended upon.

If this happened only once in a while, it would not be so bad, but in
large projects it can happen on a daily (even hourly) basis.  Thus we
need a way to release the application in pieces so that developers can
choose to depend upon older releases of the categories that they
depend upon.

However, when there are dependency cycles, then this rational scheme
for developing applications breaks down.  All of the categories within
the cycle must be released simultaneously.

Consider the following diagram:

                  +---------------+
                  | Control Panel |
                  +---------------+
                     / 	     \
	   +-----------+     +---------+
           | Transport |     | Revenue |
           +-----------+     +---------+
	    /       \               \
   +----------+ +----------+   +----------+
   | Elevator | | Conveyor |   | Database |
   +----------+ +----------+   +----------+
       	     \ 	  /
	   +-------+