以下内容首次出现在2010年1月/ 2月的“Code Magazine”杂志上，并于“S.O.L.I.D. Software Development,One Step at a Time”在线提供

The Single Responsibility Principle
says that a class should have one,and
only one,reason to change.

This may seem counter-intuitive at
first. Wouldn’t it be easier to say
that a class should only have one
reason to exist? Actually,no-one
reason to exist could very easily be
taken to an extreme that would cause
more harm than good. If you take it to
that extreme and build classes that
have one reason to exist,you may end
up with only one method per class.
This would cause a large sprawl of
classes for even the most simple of
processes,causing the system to be
difficult to understand and difficult
to change.

The reason that a class should have
one reason to change,instead of one
reason to exist,is the business
context in which you are building the
system. Even if two concepts are
logically different,the business
context in which they are needed may
necessitate them becoming one and the
same. The key point of deciding when a
class should change is not based on a
purely logical separation of concepts,
but rather the business’s perception
of the concept. When the business
perception and context has changed,
then you have a reason to change the
class. To understand what
responsibilities a single class should
have,you need to first understand
what concept should be encapsulated by
that class and where you expect the
implementation details of that concept
to change.

Consider an engine in a car,for
example. Do you care about the inner
working of the engine? Do you care
that you have a specific size of
piston,camshaft,fuel injector,etc?
Or,do you only care that the engine
operates as expected when you get in
the car? The answer,of course,
depends entirely on the context in
which you need to use the engine.

If you are a mechanic working in an
auto shop,you probably care about the
inner workings of the engine. You need
to know the specific model,the
varIoUs part sizes,and other
specifications of the engine. If you
don’t have this information available,
you likely cannot service the engine
appropriately. However,if you are an
average everyday person that only
needs transportation from point A to
point B,you will likely not need that
level of information. The notion of
the individual pistons,spark plugs,
pulleys,belts,etc.,is almost
meaningless to you. You only care that
the car you are driving has an engine
and that it performs correctly.

The engine example drives straight to the heart of the Single Responsibility Principle. The contexts of driving the car vs. servicing the engine provide two different notions of what should and should not be a single concept-a reason for change. In the context of servicing the engine,every individual part needs to be separate. You need to code them as single classes and ensure they are all up to their individual specifications. In the context of driving a car,though,the engine is a single concept that does not need to be broken down any further. You would likely have a single class called Engine,in this case. In either case,the context has determined what the appropriate separation of responsibilities is.