『面试的底气』—— 设计模式遵循的原则,设计模式之单一职责原则
Bob 大叔提出并发扬了 S.O.L.I.D 五大原则,用来更好地进行面向对象编程,五大原则分别是:
- The Single Responsibility Principle(单一职责 SRP)
- The Open/Closed Principle(开闭原则 OCP)
- The Liskov Substitution Principle(里氏替换原则 LSP)
- The Interface Segregation Principle(接口分离原则 ISP)
- The Dependency Inversion Principle(依赖反转原则 DIP)
官方定义
单一职责原则,英文缩写 SRP,全称 Single Responsibility Principle。
原始定义:There should never be more than one reason for a class to change。
官方翻译:应该有且仅有一个原因引起类的变更。
我的理解
在理解单一职责原则之前,来回顾一下类的定义:具有相同的属性和功能的对象的抽像的集合。里面有两个关键词:对象和抽象。
对象是一个自包含的实体,可用一组可识别的特性和行为来标识,比如说“人”就是一个对象,其有眼睛、鼻子、嘴巴等可识别的特性,还有吃饭、睡觉、写代码等可识别的行为。
“人”与“人”之间有不同的属性比如男性和女性,有不同的功能比如前端开发者和后端开发者,有相同的属性比如有眼睛、有鼻子,有相同的功能比如会吃饭、会睡觉。抽象的作用就是把相同的属性和功能提取处理,最后组成一个集合,叫做“人类”,那么“人类”就是一个类。
然后用一个例子来理解单一职责原则,比如你是房东,出租一套房子。租客可以当作一个个对象,房子可以看作一个类。租客(对象)会影响房子(类)给房东带来的房租。
单一职责原则就是要求房子只租给一个租客,只有一个租客会影响房子给房东带来的房租(一个原因引起类的变更)。如是出租给几个互相不认识的人,则会有好几个人会影响你的房租收入(好几个原因引起类的变更)。
用代码来表示:
class House {
constructor(param) {
this.data = param;
this.name = param.name;
//...
}
countMoney(data){
//...
}
payMoney(){
let data;
//...
const money = this.countMoney(this.data)
}
}
以上代码的类 House 代表房子,里面集合了租客,countMoney
方法用于计算房租,payMoney
用于支房租。当new House(param)
时就创建一套房子,通过param
传递租客信息进去。
此时设想一下,起先租客只有一个人。计算租金很好算,countMoney
方法中的逻辑很好写。后来又加了一些租客,countMoney
方法得重写,出错还影响其他租客支付房租,甚至有些租客由于房租计算的规则不满意,不租了,这就影响到房东的房租收入。所以房子只出租给一个人,房租最好算,不会影响到房东的房租收入。
当然实际生活说,房子不可能只出租给一个人,也可以出租给一家子或者二房东,房东只跟一个租客结算房租,这样countMoney
方法不至于频繁修改,只有向房东支付房租的租客变更后,才会去修改countMoney
方法。
以上说到了租客不可能是一个人,那么职责中不可能只有单独一个方法,甚至职责还会包含其他子职责。那么如何把众多功能分别归属到对应的职责中,还有如何划分职责,就是架构设计时要考虑的事情了。
单一职责原则不单单只应用在类中,也可以应用在普通函数中,即一个函数只处理一件事件。
作用及优点
单一职责原则的作用是控制类的粒度大小、将对象解耦、提高其内聚性。其有以下优点:
降低类的复杂度。一个类只负责一项职责,其逻辑肯定要比负责多项职责简单得多。
提高类的可读性。复杂性降低,自然其可读性会提高。
提高代码的可维护性。可读性提高,那自然更容易维护了。
变更引起的风险降低。变更是必然的,如果单一职责原则遵守得好,当修改一个功能时,可以显著降低对其他功能的影响。
单一职责
A class should have only one reason to change类发生更改的原因应该只有一个
一个类(JavaScript 下应该是一个对象)应该有一组紧密相关的行为的意思是什么?遵守单一职责的好处是可以让我们很容易地来维护这个对象, 当一个对象封装了很多职责的话,一旦一个职责需要修改,势必会影响该对象想的其它职责代码。通过解耦可以让每个职责工更加有弹性地变化。
不过,我们如何知道一个对象的多个行为构造多个职责还是单个职责?我们可以通过参考Object Design: Roles, Responsibilies, and Collaborations一书提出的 Role Stereotypes 概念来决定,该书提出了如下 Role Stereotypes 来区分职责:
- Information holder – 该对象设计为存储对象并提供对象信息给其它对象。
- Structurer – 该对象设计为维护对象和信息之间的关系
- Service provider – 该对象设计为处理工作并提供服务给其它对象
- Controller – 该对象设计为控制决策一系列负责的任务处理
- Coordinator – 该对象不做任何决策处理工作,只是 delegate 工作到其它对象上
- Interfacer – 该对象设计为在系统的各个部分转化信息(或请求)
一旦你知道了这些概念,那就狠容易知道你的代码到底是多职责还是单一职责了。
实例代码
该实例代码演示的是将商品添加到购物车,代码非常糟糕,代码如下:
function Product(id, description) { this.getId = function () { return id; }; this.getDescription = function () { return description; };}function Cart(eventAggregator) { var items = []; this.addItem = function (item) { items.push(item); };}(function () { var products = [new Product(1, "Star Wars Lego Ship"), new Product(2, "Barbie Doll"), new Product(3, "Remote Control Airplane")],cart = new Cart(); function addToCart() { var productId = $(this).attr('id'); var product = $.grep(products, function (x) { return x.getId() == productId; })[0]; cart.addItem(product); var newItem = $('<li></li>').html(product.getDescription()).attr('id-cart', product.getId()).appendTo("#cart"); } products.forEach(function (product) { var newItem = $('<li></li>').html(product.getDescription()) .attr('id', product.getId()) .dblclick(addToCart) .appendTo("#products"); });})();
该代码声明了 2 个 function 分别用来描述 product 和 cart,而匿名函数的职责是更新屏幕和用户交互,这还不是一个很复杂的例子,但匿名函数里却包含了很多不相关的职责,让我们来看看到底有多少职责:
- 首先,有 product 的集合的声明
- 其次,有一个将 product 集合绑定到#product 元素的代码,而且还附件了一个添加到购物车的事件处理
- 第三,有 Cart 购物车的展示功能
- 第四,有添加 product item 到购物车并显示的功能
重构代码
让我们来分解一下,以便代码各自存放到各自的对象里,为此,我们参考了 martinfowler 的事件聚合(Event Aggregator)理论在处理代码以便各对象之间进行通信。
首先我们先来实现事件聚合的功能,该功能分为 2 部分,1 个是 Event,用于 Handler 回调的代码,1 个是 EventAggregator 用来订阅和发布 Event,代码如下:
function Event(name) { var handlers = []; this.getName = function () { return name; }; this.addHandler = function (handler) { handlers.push(handler); }; this.removeHandler = function (handler) { for (var i = 0; i < handlers.length; i++) { if (handlers[i] == handler) { handlers.splice(i, 1); break; } } }; this.fire = function (eventArgs) { handlers.forEach(function (h) { h(eventArgs); }); }; } function EventAggregator() { var events = []; function getEvent(eventName) { return $.grep(events, function (event) { return event.getName() === eventName; })[0]; } this.publish = function (eventName, eventArgs) { var event = getEvent(eventName); if (!event) { event = new Event(eventName); events.push(event); } event.fire(eventArgs); }; this.subscribe = function (eventName, handler) { var event = getEvent(eventName); if (!event) { event = new Event(eventName); events.push(event); } event.addHandler(handler); }; }
然后,我们来声明 Product 对象,代码如下:
function Product(id, description) { this.getId = function () { return id; }; this.getDescription = function () { return description; };}
接着来声明 Cart 对象,该对象的 addItem 的 function 里我们要触发发布一个事件 itemAdded,然后将 item 作为参数传进去。
function Cart(eventAggregator) { var items = []; this.addItem = function (item) { items.push(item); eventAggregator.publish("itemAdded", item); };}
CartController 主要是接受 cart 对象和事件聚合器,通过订阅 itemAdded 来增加一个 li 元素节点,通过订阅 productSelected 事件来添加product。
function CartController(cart, eventAggregator) { eventAggregator.subscribe("itemAdded", function (eventArgs) { var newItem = $('<li></li>').html(eventArgs.getDescription()).attr('id-cart', eventArgs.getId()).appendTo("#cart"); }); eventAggregator.subscribe("productSelected", function (eventArgs) { cart.addItem(eventArgs.product); });}
Repository 的目的是为了获取数据(可以从 ajax 里获取),然后暴露 get 数据的方法。
function ProductRepository() { var products = [new Product(1, "Star Wars Lego Ship"), new Product(2, "Barbie Doll"), new Product(3, "Remote Control Airplane")]; this.getProducts = function () { return products; }}
ProductController 里定义了一个 onProductSelect 方法,主要是发布触发 productSelected 事件,forEach 主要是用于绑定数据到产品列表上,代码如下:
function ProductController(eventAggregator, productRepository) { var products = productRepository.getProducts(); function onProductSelected() { var productId = $(this).attr('id'); var product = $.grep(products, function (x) { return x.getId() == productId; })[0]; eventAggregator.publish("productSelected", { product: product }); } products.forEach(function (product) { var newItem = $('<li></li>').html(product.getDescription()) .attr('id', product.getId()) .dblclick(onProductSelected) .appendTo("#products"); });}
最后声明匿名函数(需要确保 HTML 都加载完了才能执行这段代码,比如放在 jQuery 的 ready 方法里):
(function () { var eventAggregator = new EventAggregator(),cart = new Cart(eventAggregator),cartController = new CartController(cart, eventAggregator),productRepository = new ProductRepository(),productController = new ProductController(eventAggregator, productRepository);})();
可以看到匿名函数的代码减少了很多,主要是一个对象的实例化代码,代码里我们介绍了 Controller 的概念,他接受信息然后传递到 action,我们也介绍了 Repository 的概念,主要是用来处理 product 的展示,重构的结果就是写了一大堆的对象声明,但是好处是每个对象 有了自己明确的职责,该展示数据的展示数据,改处理集合的处理集合,这样耦合度就非常低了。
最终代码
function Event(name) {
var handlers = [];
this.getName = function () {
return name;
};
this.addHandler = function (handler) {
handlers.push(handler);
};
this.removeHandler = function (handler) {
for (var i = 0; i < handlers.length; i++) {
if (handlers[i] == handler) {
handlers.splice(i, 1);
break;
}
}
};
this.fire = function (eventArgs) {
handlers.forEach(function (h) {
h(eventArgs);
});
};
}
function EventAggregator() {
var events = [];
function getEvent(eventName) {
return $.grep(events, function (event) {
return event.getName() === eventName;
})[0];
}
this.publish = function (eventName, eventArgs) {
var event = getEvent(eventName);
if (!event) {
event = new Event(eventName);
events.push(event);
}
event.fire(eventArgs);
};
this.subscribe = function (eventName, handler) {
var event = getEvent(eventName);
if (!event) {
event = new Event(eventName);
events.push(event);
}
event.addHandler(handler);
};
}
function Product(id, description) {
this.getId = function () {
return id;
};
this.getDescription = function () {
return description;
};
}
function Cart(eventAggregator) {
var items = [];
this.addItem = function (item) {
items.push(item);
eventAggregator.publish("itemAdded", item);
};
}
function CartController(cart, eventAggregator) {
eventAggregator.subscribe("itemAdded", function (eventArgs) {
var newItem = $("<li></li>")
.html(eventArgs.getDescription())
.attr("id-cart", eventArgs.getId())
.appendTo("#cart");
});
eventAggregator.subscribe("productSelected", function (eventArgs) {
cart.addItem(eventArgs.product);
});
}
function ProductRepository() {
var products = [
new Product(1, "Star Wars Lego Ship"),
new Product(2, "Barbie Doll"),
new Product(3, "Remote Control Airplane"),
];
this.getProducts = function () {
return products;
};
}
function ProductController(eventAggregator, productRepository) {
var products = productRepository.getProducts();
function onProductSelected() {
var productId = $(this).attr("id");
var product = $.grep(products, function (x) {
return x.getId() == productId;
})[0];
eventAggregator.publish("productSelected", { product: product });
}
products.forEach(function (product) {
var newItem = $("<li></li>")
.html(product.getDescription())
.attr("id", product.getId())
.dblclick(onProductSelected)
.appendTo("#products");
});
}
(function () {
var eventAggregator = new EventAggregator(),
cart = new Cart(eventAggregator),
cartController = new CartController(cart, eventAggregator),
productRepository = new ProductRepository(),
productController = new ProductController(
eventAggregator,
productRepository
);
})();
总结
看到这个重构结果,有博友可能要问了,真的有必要做这么复杂么?我只能说:要不要这么做取决于你项目的情况。如果你的项目是个是个非常小的项目,代码也不是很多,那其实是没有必要重构得这么复杂,但如果你的项目是个很复杂的大型项目,或者你的小项目将来可能增长得很快的话,那就在前期就得考虑 SRP 原则进行职责分离了,这样才有利于以后的维护。
难点
遵循单一职责原则的过程中,最大的难点就是职责如何划分,划分过细,会导致类过多,也会导致维护困难,划分过粗,可能会违背单一职责原则。