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

1:设计模式应用不应用,取决于对现在和未来判断后的取舍.没必要用尽量不用!

2.设计模式的目的是  减少复杂度(一个函数中包含的功能个数), 降低耦合度(一个对象与其他对象的关系个数).耦合度不能为0,越小越好,复杂度最小是1;

如一个function里,即用ajax来获取数据,又把返回数据渲染到页面,复杂度就是2,可以分开,降低复杂度必然增加至少一条关系,即增加了总体的耦合度.但个体的耦合度是1,这没有什么不好.

3复杂度的降低靠单一职责原则,开闭原则和里氏代换原则.

单一职责原则:一个函数只有一个功能.

一个例子:

//打开网站后,走缓存,渲染;

//如果在线,点击按钮,走网络,并添加缓存

//如果不在线,点击按钮也不生效.

先拆分功能: 缓存有关的添加和获取, 渲染  , 网络请求数据.

然后这样拆分以后,就可以有很大的扩展性,并且可以很清晰的看出来各个代码块是干嘛的.用起来也很顺手

//获取网络数据功能

function GetData(ul, data,callBackArr) {

this.getData = function(){

$ajax({

ul: ul,

data: data,

success: function(json){

var arr = JSON.parse(json);

callBackArr.forEach(function(ele){

ele(arr);

})

}

})

}

}

// 渲染功能

function Render(dom) {

this.dom = dom;

this.render = function () {

var html = ‘‘;

arr.forEach(element => {

html += ‘<li>‘ + element + ‘</li>‘

});

this.dom.append($html)

}

}

//设置和取得缓存功能

function CacheData(type,data) {

this.setCacheData = function(type,data){

localStorage.setItem(type,data)

}

this.getCacheData = function(type){

return localStorage.getItem(type);

}

}

var oC = new CacheData()

var oRender = new Render(‘ul‘);

oRender.render(oC.getCacheData(type));

btn.onclick = function(){

if(navigator.onLine){

oRender.render(GetData(ul, data,[oRender.render,oC.setCacheData]));

}

}

function GetData(ul, data,callBackArr) {

this.getData = function(){

$ajax({

ul: ul,

data: data,

success: function(json){

var arr = JSON.parse(json);

callBackArr.forEach(function(ele){

ele(arr);

})

}

})

}

}

function Render(dom) {

this.dom = dom;

this.render = function () {

var html = ‘‘;

arr.forEach(element => {

html += ‘<li>‘ + element + ‘</li>‘

});

this.dom.append($html)

}

}

//把缓存功能作为一个单独的模块拿出来,

function CacheData(type,data) {

this.setCacheData = function(type,data){

localStorage.setItem(type,data)

}

this.getCacheData = function(type){

return localStorage.getItem(type);

}

}

var oC = new CacheData()

var oRender = new Render(‘ul‘);

oRender.render(oC.getCacheData(type));

btn.onclick = function(){

if(navigator.onLine){

oRender.render(GetData(ul, data,[oRender.render,oC.setCacheData]));

}

}

原文地址:https://www.cnblogs.com/dangdanghepingping/p/10120619.html

时间: 2024-11-06 21:15:52

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

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

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

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

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

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

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

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

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

设计模式 之 单一职责原则 (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 respon

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

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

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

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

大话设计模式笔记 单一职责原则 开放-封闭原则

单一职责原则(SRP),就一个类而言,应该仅有一个引起它的变化原因. 个人认为这个原则过于理想化,仅有一个并不是绝对的,合理就好. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离[ASD] 如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责. MVC,可以说良好运用了这个原则,但有时候一些小项目,可直接在service执行SQL语句,也是可以的. 开放-封闭原则,说是软件实体(类.模块.函数等等)应该可以扩张,但是不可修改. 对于扩张是开放的(Open for

设计模式之单一职责原则

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