设计模式 之 单一职责原则 (Single Responsibility Principle)

Motivation

动机

In this context, a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and if in the future we need to make one change we are going to make it in the class which handles it. When we need to make a change in a class having more responsibilities the change might affect the other functionality related to the other responsibility of the class.

在本文中,责任被认为是更改问题的理由。本原则要求如果我们有2个原因要修改类,我们就需要将这个功能分割成两个类。每个类负责一个职责,如果将来我们需要做更改,就需要在这个职责的类中修改它。当我们修改一个多职责的类时,很可能会影响这个类中关联其他职责的功能。

The Single Responsibility Principle is a simple and intuitive principle, but in practice it is sometimes hard to get it right.

单一职责原则是一个简单易懂的规则,但是在实践中却很难正确使用。

Intent

目的

A class should have only one reason to change.

一个类只应该有一个更改的理由。

Example

示例

Let‘s assume we need an object to keep an email message. We are going to use the IEmail interface from the below sample. At the first sight everything looks just fine. At a closer look we can see that our IEmail interface and Email class have 2 responsibilities (reasons to change). One would be the use of the class in some email protocols such as pop3 or imap. If other protocols must be supported the objects should be serialized in another manner and code should be added to support new protocols. Another one would be for the Content field. Even if content is a string maybe we want in the future to support HTML or other formats.

假设我们需要一个对象来保存邮件消息,下面我们将使用IEmail接口来举例。乍看上去一切都很好,但是仔细看我们发现IEmail接口和Email类有2个职责(更改的理由)。一个职责是类使用的邮件协议,如pop3或者imap,如果必须支持其他协议,对象则需要被序列化成其他形式,代码也就需要添加对新协议的支持。另一个职责是内容Content区域,即使内容是字符串,可能将来我们也需要支持HTML或者其他格式。

If we keep only one class, each change for a responsibility might affect the other one:

  • Adding a new protocol will create the need to add code for parsing and serializing the content for each type of field.
  • Adding a new content type (like html) make us to add code for each protocol implemented.

如果我们只使用一个类,每次为了一个职责的更改都可能影响其他职责:

  • 添加新的协议将需要添加代码来分析和序列化每个区域的内容。
  • 添加新的内容类型(如html)将需要为每种实现的协议添加代码。
 1 // single responsibility principle - bad example
 2
 3 interface IEmail {
 4     public void setSender(String sender);
 5     public void setReceiver(String receiver);
 6     public void setContent(String content);
 7 }
 8
 9 class Email implements IEmail {
10     public void setSender(String sender) {// set sender; }
11     public void setReceiver(String receiver) {// set receiver; }
12     public void setContent(String content) {// set content; }
13 }

We can create a new interface and class called IContent and Content to split the responsibilities. Having only one responsibility for each class give us a more flexible design:

  • adding a new protocol causes changes only in the Email class.
  • adding a new type of content supported causes changes only in Content class.

我们可以创建一个新的接口IContent和类Content来分割职责。每个类只有一个职责为我们提供了更灵活的设计:

  • 添加新协议只会更改Email类。
  • 添加新的内容类型支持指挥修改Content类。
 1 // single responsibility principle - good example
 2 interface IEmail {
 3     public void setSender(String sender);
 4     public void setReceiver(String receiver);
 5     public void setContent(IContent content);
 6 }
 7
 8 interface Content {
 9     public String getAsString(); // used for serialization
10 }
11
12 class Email implements IEmail {
13     public void setSender(String sender) {// set sender; }
14     public void setReceiver(String receiver) {// set receiver; }
15     public void setContent(IContent content) {// set content; }
16 }

Conclusion

结论

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of responsibilities is done only when the full picture of how the application should work is well understand.

单一职责原则提供了一个在应用设计阶段识别类的好方法,它提醒你去思考类所有可能变化的方式。只有对应用程序的全貌能够很好的理解时,才能建立良好的职责划分。

原文地址:https://www.oodesign.com/single-responsibility-principle.html

原文地址:https://www.cnblogs.com/wanpengcoder/p/12683327.html

时间: 2024-11-05 14:44:22

设计模式 之 单一职责原则 (Single Responsibility Principle)的相关文章

单一职责原则(Single Responsibility Principle SRP)

对于单一职责原则,其核心思想为: 一个类,最好只做一件事,只有一个引起它的变化. 单一职责原则可以看做是低耦合.高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因. 职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而大大损伤其内聚性和耦合度. 通常意义下的单一职责,就是指只有一种单一功能,不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因.

Java 设计模式(十) 单一职责原则(SRP)

单一职责原则(Single Responsibility Principle) SRP 基本概念 单一职责原则 定义:应该有且仅有一个原因引起类的变更,也就是接口或类和职责的关系是一一对应的. 难点:职责的划分: 在不同情景和生产环境下我们对职责的细化是不同的(职责单一的相对性) 单一职责原则提出的是一个评价接口是否优良的标准,但是职责和变化原因是不可度量的,因项目而异,因环境而异(不可度量性) 优势: 类的复杂性降低:每个类或接口都只实现单一的职责,定义明确清晰 可读性提高:定义明确清晰,自然

设计模式之单一职责原则

一.单一职责(Single Responsibility Principle,简称SRP ): 一个类只负责一项职责 原始定义:There should never be more than one reason for a class to change. 官方翻译:应该有且仅有一个原因引起类的变更.简单点说,一个类,最好只负责一件事,只有一个引起它变化的原因. 错误示范: public interface IPhotograph { void photograph(); } public i

学习大话设计模式03_单一职责原则

单一职责原则:一个类,应仅有一个引起它变化的原因 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分享.如果你能够想到多于一个的动机去改变一个类,那么这个类就是具有多于一个的职责 学习大话设计模式03_单一职责原则

设计模式之单一职责原则(SRP)

自己之前写过一些关于设计模式的博客,但是大部分都写得比较匆忙.现在正好趁年前有时间,笔者打算好好地整理一下自己这块知识结构.开篇的第一个原则就是设计原则里面最简单的一个原则--单一职责原则. 想必大家都听过并且常用这个原则进行一些项目的重构,因为这个原则太简单了,一句话概括就是:应该有且仅有一个原因引起类的变更.但是我们在实际的项目里面不能够生搬硬套,因为单一职责原则有个缺点就是可能会造成类对象的剧增,导致我们在用的时候就需要人为的组合对象.大家应该知道组合操作就会造成冗余.耦合,所以可以视具体

前端中会用到的设计模式之单一职责原则

1:设计模式应用不应用,取决于对现在和未来判断后的取舍.没必要用尽量不用! 2.设计模式的目的是  减少复杂度(一个函数中包含的功能个数), 降低耦合度(一个对象与其他对象的关系个数).耦合度不能为0,越小越好,复杂度最小是1; 如一个function里,即用ajax来获取数据,又把返回数据渲染到页面,复杂度就是2,可以分开,降低复杂度必然增加至少一条关系,即增加了总体的耦合度.但个体的耦合度是1,这没有什么不好. 3复杂度的降低靠单一职责原则,开闭原则和里氏代换原则. 单一职责原则:一个函数只

设计模式(3)-----单一职责原则

单一职责原则(SRP) 定义 就一个类而言,应该仅有一个引起它变化的原因.一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离. 例子 例如在做一个根据参数对用户表进行查询再显示出来的功能,把这些东西写在一个类里面是非常不好的.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个

《大话设计模式》——单一职责原则

单一职责原则(SRP):就一个类而言,应该仅有一个能引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 如果能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.就应该考虑类的职责分离.

设计模式之单一职责原则(iOS开发,代码用Objective-C展示)

单一职责原则:就一个类而言,应该只有一个引起它变化的原因. 在iOS开发中,我们会很自然的给一个类添加各种各样的功能,比如随便写一个简单的应用程序,一般都会生成一个viewController类,于是我们将各种各样的代码,商业运算的算法.http请求的参数(params)封装.使用FMDB.coreData时的数据库访问语句都放在这个类里面,这就意味着,无论任何需求变化,都要来修改viewController这个类,这其实是很糟糕的,维护麻烦.复用不可能.缺乏灵活性. 也许上面说的略微夸张,因为