ood.txt

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

           | Alarm |
	   +-------+

The developers that are working in the 'Transport' category choose to
work with older, more stable, versions of Elevator and Conveyor, which
in turn depend upon an old version of Alarm.  When Transport wants to
make a release, they simply test their category with the appopriate
releases of the dependent categories, and then release it.

However, if Alarm called a function that belonged to 'Control Panel',
thus creating a cyclic dependency, then Transport could not work
without old and stable versions of Elevator and Conveyor, which could
not work without a stable verion of Alarm, which could not work
without a stable version of Control Panel, which needs a stable
version of Transport.  Since we are trying to make changes to
Transport, all of the other categories are suddenly invalidated, and
the entire cycle must be released at the same time.

Thus, cycles in the dependency structure interfere with the ability to
release an application in pieces.  However there is even more harm
that they can do.  Consider again the diagram above.  The developers
working in 'Elevators' want to run some unit tests.  They must link
with Alarm.  However, if we assume that the same cycle exists, (i.e.
Alarm calls a function in Control Panel) then the unit test must link
with Control Panel, which must link with Revenue, which must link with
the Database.  And the database doesn't work.

The developers of 'Elevator' are really angry.  They don't need the
database.  They don't want to link with the database.  The database
code is 14 megabytes and takes 45 minutes to link in; so why do they
have to use it?  The 'Elevator' developers go find the developer in
'Alarm' who created the cyclic dependency upon 'Control Panel' and
take him out back for a little lesson in software engineering.

***  How can the cycle be broken.  Simple.  Whenever there is a cycle
in the dependency graph of class categories, that cycle can be broken
by splitting one of the categories into two.  In this case, we could
split the 'Control Panel' category into two categories as shown below:

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

The new category 'Control Panel Utilities' contains the function that
Alarm wants to call.

--------------------------------------------------------------------
   8. Dependencies between released categories must run in the
      direction of stability.  The dependee must be more stable than
      the depender.
--------------------------------------------------------------------

One could view this as a axiom, rather than a principle, since it
is impossible for a category to be more stable than the categories
that it depends upon.  When a category changes it always affects the
dependent categories (even if for nothing more than a
retest/revalidation).  However the principle is meant as a guide to
designers.  Never cause a category to depend upon less stable
categories.  

What is stability?  The probable change rate.  A category that is
likely to undergo frequent changes is instable.  A category that will
change infrequently, if at all, is stable.

There is an indirect method for measuring stability.  It employs the
axiomatic nature of this principle.  Stability can be measured as a
ratio of the couplings to classes outside the category.

A category which many other categories depend upon is inherently
stable.  The reason is that such a category is difficult to change.
Changing it causes all the dependent categories to change.  

On the other hand, a category which depends on many other categories
is instable, since it must be changed whenever any of the categories
it depends upon change.

A category which has many dependents, but no dependees is ultimately
stable since it has lots of reason not to change and no reason to
change. (This ignores the categories intrinsic need to change based
upon bugs and feature drift). 

A category that depends upon many categories but has no dependents is
ultimately instable since it has no reason not to change, and is
subject to all the changes coming from the categories it depends upon.

So this notion of stability is positional rather than absolute.  It
measures stability in terms of a category's position in the dependency
hierarchy.  It says nothing about the subjective reasons that a
category might need changing, and focuses only upon the objective,
physical reasons that facilitate or constrain changes.

To calculate the Instability of a category (I) count the number of
classes, outside of the category, that depend upon classes within the
category.  Call this number Ca.  Now count the number of classes
outside the category that classes within the category depend upon.
Call this number Ce.  I = Ce / (Ca + Ce).  This metric ranges from 0
to 1, where 0 is ultimately stable, and 1 is ultimately instable. 

In a dependency hierarchy, wherever a category with a low I value
depends upon a category with a high I value, the dependent category
will be subject to the higher rate of change of the category that it
depends upon.  That is, the category with the high I metric acts as a
collector for all the changes below it, and funnels those changes up
to the category with the low I metric. 

Said another way, a low I metric indicates that there are many
relatively many dependents.  We don't want these dependents to be
subject to high rates of change.  Thus, if at all possible, categories
should be arranged such that the categories with high I metrics should
depend upon the categories with low I metrics.

--------------------------------------------------------------------
   9. The more stable a class category is, the more it must
      consist of abstract classes.  A completely stable category
      should consist of nothing but abstract classes.
--------------------------------------------------------------------

The stability being referred to in this principle, is again the I
metric which is based upon "positional" stability.  That is, a module
that is in a highly stable position in the dependency graph should
also be highly abstract.  

The justification for this principle is based upon the idea that
executable code (The implementations of methods) changes more often
than the interfaces between modules.  Therefore interfaces have more
intrinsic stability than executable code.  In C++, it is more likely
that you will change a .cc file than a .h file.

In some languages, the division between implementation and interface
is very clear cut.  But in others (like C++) it is blurred.  The
stability of the .h file is not as great as it could be because
private functions and private variables are likely to need changing as
the implementation evolves.  In such languages, the maximum stability
comes from pure interfaces.  A class that contains pure interfaces is
an abstract class.

Thus, we can measure the abstraction of a category by computing the
ratio of abstract classes to total classes:

      A = (# abstract classes) / (# of classes).

For example, if a class category contains 10 classes, of which 6 are
abstract then A = .6.  A will always range from [0,1].

Principle 9 says that categories that are placed into positions of
stability ought to be abstract.  The reason for this that the higher
the abstraction of the category, the higher its intrinsic stability.
And since intrinsic stability is limited by positional stability,
intrinsically stable modules should also have positional stability.

Consider a category with very low abstraction.  Such a category has
mostly concrete classes in it.  If it is put in a place of stability,
then many other categories will depend upon it.  And thus, it will be
difficult to change its implementation.  On the other hand, consider a
category with very high abstraction.  Such a category consists mostly
of abstract classes.  If we put this category into a position of very
low stability, then very few other categories will depend upon it.
And then, of what use is the abstract interface?

But there is another reason to put abstractions in positions of
stability.  And that reason goes back to principle #1; the open closed
principle.  We want concrete categories to depend upon abstract
categories so that the derivatives of those abstract categories can be
controlled by the concrete categories.  This is reuse.  The concrete
categories can be reused with different derivatives of the abstract
categories.  Also, when the implementations of those derivative
categories change, the abstract category is not affected, and so the
concrete categories that depend upon it are also unaffected.  Thus,
the concrete categories are open to be extended, but do not need to be
modified in order to achieve that extension.

The open closed principle leads us to the realization that we do not
want all of our categories to be stable.  Stability is inflexibility.
A stable category is difficult to change.  And we do not want our
applications to be difficult to change.  But the open closed principle
allows that a module that is highly stable (closed for modification)
can also be open for extension.  Yet this can only happen if the
extension takes place in a derivative of the stable abstraction.
Thus, in the ideal world our models would consist of two kinds of
categories.  Completely abstract and stable categories that are
depended upon by completely concrete and instable categories.

We are now in a position to define the relationship between stability
(I) and abstractness (A).  We can create a graph with A on the
vertical axis and I on the horizontal axis.  If we plot the two "good"
kinds of categories on this graph, we will find the categories that
are maximally stable and abstract at the upper left at (0,1).  The
categories that are maximally instable and concrete are at the lower
right at (1,0).

But not all categories can fall into one of these two positions.
Categories have degrees of abstraction and stability.  For example, it
is very common that one abstract class derives from another abstract
class.  The derivative is an abstraction that has a dependency.  Thus,
though it is maximally abstract, it will not be maximally stable.  Its
dependency will decrease its stability.

Consider a category with A=0 and I=0.  This is a highly stable and
concrete category.  Such a category is not desirable because it is
rigid.  It cannot be extended because it is not abstract.  And it is
very difficult to change because of its stability.

Consider a category with A=1 and I=1.  This category is also
undesirable (perhaps impossible) because it is maximally abstract and
yet has no dependents.  It, too, is rigid because the abstractions are
impossible to extend.

But what about a category with A=.5 and I=.5?  This category is
partially extensible because it is partially abstract.  Moreover, it
is partially stable so that the extensions are not subject to maximal
instability.  Such a category seems "balanced".  Its stability is in
balance with its abstractness.

Consider again the A-I graph (below).  We can draw a line from (0,1)
to (1,0).  This line represents categories whose abstractness is
"balanced" with stability.  Because of its similarity to a graph used
in astronomy, I call this line the "Main Sequence".

               |
               |
	      1= (0,1)
	       |\
	       | \
   Abstractness|  \ The
	       |   \ Main
	       |    \ Sequence
	       |     \
	       |      \
	       |       \  (1,0)
	       +--------:--
	        	1
	          Instability


A category that sits on the main sequence is not "too abstract" for
its stability, nor is "too instable" for its abstractness.  It has the
"right" number of concrete and abstract classes in proportion to its
positional stability.  Clearly, the most desirable positions for a
category to hold are at one of the two endpoints of the main sequence.
However, in my experience only about half the categories in a project
can have such ideal characteristics.  Those other categories have the
best characteristics if they are on or close to the main sequence.

This leads us to another metric.  If it is desirable for categories
to be on or close to the main sequence, we can create a metric which
measures how far away a category is from this ideal.

D : Distance : |(A+I-1)/root2| : The perpendicular distance of a
    category from the main sequence.  This metric ranges from
    [0,~0.707].  (One can normalize this metric to range between [0,1]
    by using the simpler form |(A+I-1)|.  I call this metric D').

Given this metric, a design can be analyzed for its overall
conformance to the main sequence.  The D metric for each category can
be calculated.  Any category that has a D value that is not near zero
can be reexamined and restructured.

Statistical analysis of a design is also possible.  One can calculate
the mean and variance of all the D metrics within a design.  One would
expect a conformant design to have a mean and variance which were
close to zero.  The variance can be used to establish "control limits"
which can identify categories that are "exceptional" in comparison to
all the others.