当前位置：首页 > article >正文

软件设计模式原则（三）单一职责原则

article 2024/9/25 1:20:39

单一职责原则（SRP）又称单一功能原则。它规定一个类应该只有一个发生变化的原因。所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

一.定义

二.原理

类的单一职责原则

单一职责原则好处

三.实践

一.定义

每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起——这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。

二.原理

如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

类的单一职责原则

一般一个对象可以分为属性和行为二部分，所以在类的设计时，我们一般把对象的属性抽象成一个BO(Business Object,业务对象)，把对象的行为抽象成一个Biz(Business Logic，业务逻辑)。

单一职责原则好处

降低类的复杂性：每个类实现单一职责，并且单一职责都有清楚明确的定义，复杂性当然降低
提高可读性：类的复杂性降低了，当然提高了可读性了。
提高可维护性：类的复杂性降低，可读性好，当然好维护。
提高扩展性：变更引起的风险降低，变更是必不可少的，如果接口的单一职责做的好，一个接口修改只对相应的实现类有影响，对其它的接口没有影响，这对系统的扩展性，维护性都是有好处的。

归纳弱点：

职责多，引起此类变化的原因也多。后续变更的风险就大。
后续需求变更，会造成职责的混乱，类结构的不稳定。

三.实践

举个例子，将一个女孩追到手，有如下两种方式：

方法一
public void ChaseGirl()
{
	SentLetter();
	DevelopFeeling();
	MakeVow（）;
}

public void SentLetter()
{
	
}

public void DevelopFeeling()
{
	
}

public void MakeVow（）
{
	
}
方法二
public void ChaseGirl()
{
	SentLetterAndDevelopFeeling();
	MakeVow（）;
}

public void SentLetterAndDevelopFeeling()
{
	
}

public void MakeVow（）
{
	
}
不难看出，虽然底层的实现逻辑几乎相同，但是方法二中将送情书and发展感情耦合在了一个类中，违反了单一原则：假设有的女孩对情书不屑一顾，那么就要修改认识的方式——但此时也要修改发展感情的方法~这就是典型的耦合性高的开发~

单一职责原则的重心不在于“一”，而是如何拆分“一”：每个设计师都知道软件应该解耦和分层，但难的是何时分，以及如何分——比如有的人就认为建立契机和发展感情应该是一个统一的过程~

因此引出解决的方法：遵守单一职责原则，将不同的职责封装到不同的类或模块中。