Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the web design patterns to improve code reusability". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what web design patterns to improve code reusability.

Bridging mode

Bridge mode person, as its name, is actually equivalent to a bridge, bridging the variables of different dimensions together to achieve the function. Suppose we need to implement three shapes (rectangle, circle, triangle), and each shape has three colors (red, green, blue). This requirement has two schemes, one scheme writes nine methods, and each method implements a graph:

Function redRectangle () {} function greenRectangle () {} function blueRectangle () {} function redCircle () {} function greenCircle () {} function blueCircle () {} function redTriangle () {} function greenTriangle () {} function blueTriangle () {}

Although the function of the above code has been implemented, if our requirements change and we ask for another color, then we have to add three more methods, one for each shape. So many methods look very repetitive, which means that he has room for optimization. Let's take a closer look at this requirement. The figure we are going to draw finally has two variables: color and shape. In fact, these two variables do not have a strong logical relationship, and are completely two-dimensional variables. So we can take these two variables apart and eventually bridge them when we want to draw a graph, that's all:

Function rectangle (color) {/ / rectangular showColor (color);} function circle (color) {/ / Circular showColor (color);} function triangle (color) {/ / triangular showColor (color);} function showColor (color) {/ / method of displaying colors} / / A red circle let obj = new circle ('red') is required when used

After using the bridge mode, our method has changed from 3 * 3 to 3 + 1, and if the subsequent color increases, we only need to modify the showColor method slightly to make it support the new color. If the dimension of our variable is not 2, but 3, this advantage will be more obvious. The former method is x * y * z, and the bridge mode is x + y + z after optimization, which is directly exponential optimization. So the core idea of bridging pattern optimization here is to observe whether repetitive code can be split into multiple dimensions, if possible, separate different dimensions, and then bridge these dimensions when in use.

Examples: brush and crayon

In fact, my favorite examples of bridging mode are brushes and crayons, because this example is very intuitive and easy to understand. The requirement of this example is to draw three types of lines: fine, medium and thick, each type of line needs 5 colors, if we use crayons to draw, we need 15 crayons, if we change the brush, we only need 3 brushes. Use different colors of ink each time, just change the ink. That's what it's like to write code, a bit like the one above:

/ function smallPen (color) {this.color = color;} smallPen.prototype.draw = function () {drawWithColor (this.color); / / draw with color color} function middlePen (color) {this.color = color;} middlePen.prototype.draw = function () {drawWithColor (this.color); / / draw} function bigPen (color) {this.color = color with color color } bigPen.prototype.draw = function () {drawWithColor (this.color); / / draw with color color} / / another color class function color (color) {this.color = color;} / / use new middlePen (new color ('red')). Draw (); / / draw a medium red line new bigPen (new color (' green')). Draw (); / / draw a large green line

In the above example, crayons cannot be separated because their size and color are their own attributes. The number of crayons required is the product of two dimensions, that is, 15. If there is one more dimension, the complexity increases exponentially. But the size and color of the brush are separated, and you can bridge them together when you use them. Only three brushes and 5 bottles of ink are needed, which greatly reduces the complexity. I created a new class for the color of the above code, while in the previous example, the color of the drawing is passed directly as a parameter to demonstrate that even the same design pattern can have different implementations. Which scheme should be adopted according to our actual needs, if only a simple variable such as color is to be bridged, it can be passed as a parameter, and if you want to bridge a complex object, you may need a class. In addition, the three pen classes of the above code look very repetitive, in fact, further optimization can also extract a template, that is, the base class of the pen, you can take a look at the template method pattern below.

Example: menu item

The requirement for this example is that there are multiple menu items, each with different text, and the text color is different when you slide in and out of the mouse. We might write code like this when we generally implement it:

Function menuItem (word) {this.dom = document.createElement ('div'); this.do [XSS _ clean] = word;} var menu1 = new menuItem (' menu1'); var menu2 = new menuItem ('menu2'); var menu3 = new menuItem (' menu3'); / / set the mouse slide event menu1.dom.onmouseover = function () {menu1.dom.style.color = 'red' for each menu } menu2.dom.onmouseover = function () {menu1.dom.style1.color = 'green';} menu3.dom.onmouseover = function () {menu1.dom.style1.color =' blue';} menu1.dom.onmouseout = function () {menu1.dom.style1.color = 'green';} menu2.dom.onmouseout = function () {menu1.dom.style1.color =' blue';} menu3.dom.onmouseout = function () {menu1.dom.style1.color = 'red';}

The above code looks like a lot of repetition. In order to eliminate the duplicate code, we separate the event binding and color setting dimensions:

/ / the menu item class receives one more parameter color function menuItem (word, color) {this.dom = document.createElement ('div'); this.do [XSS _ clean] = word; this.color = color; / / adds an instance method to bind the event menuItem.prototype.bind = function () {var that = this as an instance property} / menu item class / / the this here points to the menuItem instance object this.dom.onmouseover = function () {this.style.color = that.color.colorOver; / / Note that the this here is the this in the event callback and points to the DOM node} this.dom.onmouseout = function () {this.style.color = that.color.colorOut. }} / / create another class to store colors. At present, this class is relatively simple. You can extend function menuColor (colorOver, colorOut) {this.colorOver = colorOver; this.colorOut = colorOut as needed. } / / now new menu items can be looped directly in an array var menus = [{word: 'menu1', colorOver:' red', colorOut: 'green'}, {word:' menu2', colorOver: 'green', colorOut:' blue'}, {word: 'menu3', colorOver:' blue', colorOut: 'red'},] for (var I = 0; I

< menus.length; i++) { // 将参数传进去进行实例化，最后调一下bind方法，这样就会自动绑定事件了 new menuItem(menus[i].word, new menuColor(menus[i].colorOver, menus[i].colorOut)).bind(); } 上述代码也是一样的思路，我们将事件绑定和颜色两个维度分别抽取出来，使用的时候再桥接，从而减少了大量相似的代码。 享元模式 当我们观察到代码中有大量相似的代码块，他们做的事情可能都是一样的，只是每次应用的对象不一样，我们就可以考虑用享元模式。现在假设我们有一个需求是显示多个弹窗，每个弹窗的文字和大小不同： // 已经有一个弹窗类了 function Popup() {} // 弹窗类有一个显示的方法 Popup.prototype.show = function() {} 如果我们不用享元模式，一个一个弹就是这样: var popup1 = new Popup(); popup1.show(); var popup2 = new Popup(); popup2.show(); 我们仔细观察上面的代码，发现这两个实例做的事情都是一样的，都是显示弹窗，但是每个弹窗的大小文字不一样，那show方法是不是就可以提出来公用，把不一样的部分作为参数传进去就行。这种思路其实就是享元模式，我们改造如下: var popupArr = [ {text: 'popup 1', width: 200, height: 400}, {text: 'popup 2', width: 300, height: 300}, ] var popup = new Popup(); for(var i = 0; i < popupArr.length; i++) { popup.show(popupArr[i]); // 注意show方法需要接收参数 } 实例：文件上传 我们再来看一个例子，假如我们现在有个需求是上传文件，可能需要上传多个文件，我们一般写代码可能就是这样: // 一个上传的类 function Uploader(fileType, file) { this.fileType = fileType; this.file = file; } Uploader.prototype.init = function() {} // 初始化方法 Uploader.prototype.upload = function() {} // 具体上传的方法 var file1, file2, file3; // 多个需要上传的文件 // 每个文件都实例化一个Uploader new Uploader('img', file1).upload(); new Uploader('txt', file2).upload(); new Uploader('mp3', file3).upload(); 上述代码我们需要上传三个文件于是实例化了三个Uploader，但其实这三个实例只有文件类型和文件数据不一样，其他的都是一样的，我们可以重用一样的部分，不一样的部分作为参数传进去就行了，用享元模式优化如下: // 文件数据扔到一个数组里面 var data = [ {filetype: 'img', file: file1}, {filetype: 'txt', file: file2}, {filetype: 'mp3', file: file3}, ]; // Uploader类改造一下, 构造函数不再接收参数 function Uploader() {} // 原型上的其他方法保持不变 Uploader.prototype.init = function() {} // 文件类型和文件数据其实是上传的时候才用，作为upload的参数 Uploader.prototype.upload = function(fileType, file) {} // 调用时只需要一个实例，循环调用upload就行 var uploader = new Uploader(); for(var i = 0; i < data.length; i++) { uploader.upload(data[i].filetype, data[i].file) } 上述代码我们通过参数的抽取将3个实例简化为1个，提高了Uploader类的复用性。上述两个例子其实是类似的，但他们只是享元模式的一种形式，只要是符合这种思想的都可以叫享元模式，比如jQuery里面的extend方法也用到了享元模式。 实例：jQuery的extend方法 jQuery的extend方法是大家经常用的一个方法了，他接收一个或者多个参数： 只有一个参数时，extend会将传入的参数合并到jQuery自己身上。 传入两个参数obj1和obj2时，extend会将obj2合并到obj1上。 根据上述需求，我们很容易自己实现： $.extend = function() { if(arguments.length === 1) { for(var item in arguments[0]) { this[item] = arguments[0][item] } } else if(arguments.length === 2) { for(var item in arguments[1]) { arguments[0][item] = arguments[1][item]; } } } 上述代码的this[item] = arguments[0][item]和arguments[0][item] = arguments[1][item]看着就很像，我们想想能不能优化下他，仔细看着两行代码，他们不同的地方是拷贝的目标和来源不一样，但是拷贝的操作却是一样的。所以我们用享元模式优化下，将不同的地方抽出来，保持共用的拷贝不变: $.extend = function() { // 不同的部分抽取出两个变量 var target = this; // 默认为this，即$本身 var source = arguments[0]; // 默认为第一个变量 // 如果有两个参数, 改变target和source if(arguments.length === 2) { target = arguments[0]; source = arguments[1]; } // 共同的拷贝操作保持不变 for(var item in source) { target[item] = source[item]; } } 模板方法模式 模板方法模式其实类似于继承，就是我们先定义一个通用的模板骨架，然后后面在这个基础上继续扩展。我们通过一个需求来看下他的基本结构，假设我们现在需要实现一个导航组件，但是这个导航类型还比较多，有的带消息提示，有的是横着的，有的是竖着的，而且后面还可能会新增类型： // 先建一个基础的类 function baseNav() { } baseNav.prototype.action = function(callback){} //接收一个回调进行特异性处理 上述代码我们先建了一个基础的类，里面只有最基本的属性和方法，其实就相当于一个模板，而且在具体的方法里面还可以接收回调，这样后面派生出来的类可以根据自己的需求传入回调。模板方法模式其实就是类似于面向对象的基类和派生类的关系，下面我们再来看一个例子。 实例：弹窗 还是之前用过的弹窗例子，我们要做一个大小文字可能不同的弹窗组件，只是这次我们的弹窗还有取消和确定两个按钮，这两个按钮在不同场景下可能有不同的行为，比如发起请求什么的。但是他们也有一个共同的操作，就是点击这两个按钮后弹窗都会消失，这样我们就可以把共同的部分先写出来，作为一个模板： function basePopup(word, size) { this.word = word; this.size = size; this.dom = null; } basePopup.prototype.init = function() { // 初始化DOM元素 var div = document.createElement('div'); div[xss_clean] = this.word; div.style.width = this.size.width; div.style.height = this.size.height; this.dom = div; } // 取消的方法 basePopup.prototype.cancel = function() { this.dom.style.display = 'none'; } // 确认的方法 basePopup.prototype.confirm = function() { this.dom.style.display = 'none'; } 现在我们有了一个基础的模板，那假如我们还需要在点击取消或者确认后再进行其他操作，比如发起请求，我们可以以这个模板为基础再加上后面需要的操作就行： // 先继承basePopup function ajaxPopup(word, size) { basePopup.call(this, word, size); } ajaxPopup.prototype = new basePopup(); ajaxPopup.prototype.constructor = ajaxPopup; // 上面是一个继承的标准写法，其实就相当于套用了模板 // 下面来加上需要的发起网络请求的操作 var cancel = ajaxPopup.prototype.cancel; // 先缓存模板上的cancel方法 ajaxPopup.prototype.cancel = function() { // 先调模板的cancel cancel.call(this); // 再加上特殊的处理，比如发起请求 $.ajax(); } // confirm方法是一样的处理 var confirm = ajaxPopup.prototype.confirm; ajaxPopup.prototype.confirm = function() { confirm.call(this); $.ajax(); } 上面这个例子是通过继承实现了模板方法模式，但是这个模式并不是一定要用继承的，他强调的是将一些基础部分提取出来作为模板，后面更多的操作可以在这个基础上进行扩展。 实例：算法计算器 这个例子我们就不用继承了，他的需求是我们现在有一系列的算法，但是这些算法在具体用的时候可能还会添加一些不同的计算操作，需要添加的操作可能在这个算法前执行，也可能在这个算法后执行。 // 先定义一个基本的类 function counter() { } // 类上有一个计算方法 counter.prototype.count = function(num) { // 里面有一个算法本身的基本计算方法 function baseCount(num) { // 这里的算法是什么不重要，我们这里就加1吧 num += 1; return num; } } 根据需求我们要解决的问题是在基本算法计算时可能还有其他计算操作，这些操作可能在基本计算前，也可能在基本计算之后，所以我们要在这个计算类上留出可扩展的接口： function counter() { // 添加两个队列，用于基本算法前或者后执行 this.beforeCounting = []; this.afterCounting = []; } // 添加一个接口，接收基本算法计算前应该进行的计算 counter.prototype.before = function(fn) { this.beforeCounting.push(fn); // 直接将方法放进数组里面 } // 再添加一个接口，接收基本算法计算后应该进行的计算 counter.prototype.after = function(fn) { this.afterCounting.push(fn); } // 改造计算方法，让他按照计算前-基本计算-计算后执行 counter.prototype.count = function(num) { function baseCount(num) { num += 1; return num; } var result = num; var arr = [baseCount]; // 将需要进行的计算都放到这个数组里面 arr = this.beforeCounting.concat(arr); // 计算前操作放到数组前面 arr = arr.concat(this.afterCounting); // 计算后操作放到数组后面 // 将数组全部按顺序拿出来执行 while(arr.length >

0) {result = arr.shift () (result);} return result;} / / now counter can directly use var counterIntance = new counter (); counterIntance.before (num = > num + 10); / / add 10 counterIntance.after before calculation (num = > num-5); / / subtract 5 counterIntance.count (2) after calculation; / 2 + 10 + 1-5 = 8

We don't use inheritance this time, but we still define a basic operation skeleton, and then extend the special operations needed in different places on this skeleton.

Thank you for your reading, the above is the content of "what are the web design patterns to improve code reusability". After the study of this article, I believe you have a deeper understanding of what the web design patterns to improve code reusability have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.