- 博客(61)
- 收藏
- 关注
RSS订阅转载 Vue.js——vue-router 60分钟快速入门
概述vue-router是Vue.js官方的路由插件，它和vue.js是深度集成的，适合用于构建单页面应用。vue的单页面应用是基于路由和组件的，路由用于设定访问路径，并将路径和组件映射起来。传统的页面应用，是用一些超链接来实现页面切换和跳转的。在vue-router单页面应用中，则是路径之间的切换，也就是组件的切换。本文将以示例的形式来介绍vue-router的各个特性，一共包...
2016-07-21 06:56:00
950
转载 Vue.js——60分钟webpack项目模板快速入门
概述 browserify是一个 CommonJS风格的模块管理和打包工具，上一篇我们简单地介绍了Vue.js官方基于browserify构筑的一套开发模板。webpack提供了和browserify类似的功能，在前端资源管理这方面，它提供了更加出色的功能。官方基于webpack提供了两种项目模板，分别是vue-webpack-simple模板和vue-webpack模板，今天我们将介绍...
2016-07-17 13:37:00
246
转载 Vue.js——60分钟browserify项目模板快速入门
概述 在之前的一系列vue.js文章，我们都是用传统模式引用vue.js以及其他的js文件的，这在开发时会产生一些问题。 首先，这限定了我们的开发模式是基于页面的，而不是基于组件的，组件的所有代码都直接写在页面中，这对于一些复杂的页面来说，不是好事情，代码的可读性会较差，也不便于管理。 其次，定义在HTML页面中的组件，无法被其他页面重用，我们只能通过复制粘贴的方式将组件代码拷贝到其他页...
2016-07-16 18:48:00
268
转载 Vue.js——使用$.ajax和vue-resource实现OAuth的注册、登录、注销和API调用
概述 上一篇我们介绍了如何使用vue resource处理HTTP请求，结合服务端的REST API，就能够很容易地构建一个增删查改应用。这个应用始终遗留了一个问题，Web App在访问REST API时，没有经过任何认证，这使得服务端的REST API是不安全的，只要有人知道api地址，就可以调用API对服务端的资源进行修改和删除。今天我们就来探讨一下如何结合Web API来限制资源的...
2016-07-13 10:29:00
513
转载 Vue.js——vue-resource全攻略
概述上一篇我们介绍了如何将$.ajax和Vue.js结合在一起使用，并实现了一个简单的跨域CURD示例。Vue.js是数据驱动的，这使得我们并不需要直接操作DOM，如果我们不需要使用jQuery的DOM选择器，就没有必要引入jQuery。vue-resource是Vue.js的一款插件，它可以通过XMLHttpRequest或JSONP发起请求并处理响应。也就是说，$.ajax能做的...
2016-07-10 08:02:00
1270
转载 Vue.js——基于$.ajax实现数据的跨域增删查改
概述 之前我们学习了Vue.js的一些基础知识，以及如何开发一个组件，然而那些示例的数据都是local的。在实际的应用中，几乎90%的数据是来源于服务端的，前端和服务端之间的数据交互一般是通过ajax请求来完成的。 说起ajax请求，大家第一时间会想到jQuery。除了拥有强大的DOM处理能力，jQuery提供了较丰富的ajax处理方法，它不仅支持基于XMLHttpRequest的aja...
2016-07-07 06:35:00
591
转载 Vue.js——60分钟组件快速入门（下篇）
概述 上一篇我们重点介绍了组件的创建、注册和使用，熟练这几个步骤将有助于深入组件的开发。另外，在子组件中定义props，可以让父组件的数据传递下来，这就好比子组件告诉父组件：“嘿，老哥，我开通了一个驿站，你把东西放到驿站我就可以拿到了。” 今天我们将着重介绍slot和父子组件之间的访问和通信，slot是一个非常有用的东西，它相当于一个内容插槽，它是我们重用组件的基础。Vue的事件系统独立...
2016-07-03 12:17:00
560
转载 Vue.js——60分钟组件快速入门（上篇）
组件简介组件系统是Vue.js其中一个重要的概念，它提供了一种抽象，让我们可以使用独立可复用的小组件来构建大型应用，任意类型的应用界面都可以抽象为一个组件树：那么什么是组件呢？组件可以扩展HTML元素，封装可重用的HTML代码，我们可以将组件看作自定义的HTML元素。本文的Demo和源代码已放到GitHub，如果您觉得本篇内容不错，请点个赞，或在GitHub上加个星星！（...
2016-06-29 07:18:00
1198
转载 Vue.js——60分钟快速入门
Vue.js介绍 Vue.js是当下很火的一个JavaScript MVVM库，它是以数据驱动和组件化的思想构建的。相比于Angular.js，Vue.js提供了更加简洁、更易于理解的API，使得我们能够快速地上手并使用Vue.js。 如果你之前已经习惯了用jQuery操作DOM，学习Vue.js时请先抛开手动操作DOM的思维，因为Vue.js是数据驱动的，你无需手动操作DOM。它通过一...
2016-06-27 06:54:00
814
转载 酷酷的CSS3三角形运用
概述 在早期的前端Web设计开发年代，完成一些页面元素时，我们必须要有专业的PS美工爸爸，由PS美工爸爸来切图，做一些圆角、阴影、锯齿或者一些小图标。 在CSS3出现后，借助一些具有魔力的CSS3属性，使得这些元素大多都可以由开发人员自己来完成。在开始阅读这篇文章前，我们先喊个口号：不想当艺术家的程序员不是好设计师！ 本文的Demo和源代码已放到GitHub，如果您觉得本篇内容不错，请点...
2016-06-25 14:40:00
197
转载 玩转JavaScript OOP[4]——实现继承的12种套路
概述 在之前的文章中，我们借助构造函数实现了“类”，然后结合原型对象实现了“继承”，并了解了JavaScript中原型链的概念。 理解这些内容，有助于我们更深入地进行JavaScript面向对象编程。 由于JavaScript是一门基于对象和原型的弱语言，灵活度非常高，这使得JavaScript有各种套路去实现继承。本篇文章将逐一介绍实现继承的12种套路，它们可以适用于不同的场景，总一种...
2016-06-16 21:51:00
111
转载 玩转JavaScript OOP[3]——彻底理解继承和原型链
概述 上一篇我们介绍了通过构造函数和原型可以实现JavaScript中的“类”，由于构造函数和函数的原型都是对象，所以JavaScript的“类”本质上也是对象。这一篇我们将介绍JavaScript中的一个重要概念原型链，以及如何经原型链实现JavaScript中的继承。 C#的继承 首先，我们简单描述一下继承的概念：当一个类和另一个类构成"is a kind of"关系时，这两个类就构...
2016-06-10 07:18:00
185
转载 玩转JavaScript OOP[2]——类的实现
概述 当我们在谈论面向对象编程时，我们在谈论什么？我们首先谈论的是一些概念：对象、类、封装、继承、多态。对象和类是面向对象的基础，封装、继承和多态是面向对象编程的三大特性。 JavaScript提供了对象却缺乏类，它不能像C#一样能显式地定义一个类。但是JavaScript的函数功能非常灵活，其中之一就是构造函数，结合构造函数和原型对象可以实现”类”。 对象和类的概念 对象 “对象”是面...
2016-06-07 22:07:00
112
转载 玩转JavaScript OOP[1]——复杂类型
概述 在JavaScript中，我们可以使用函数、数组、对象，以及日期、正则等一些内置类型的实例，它们都是复杂类型的表现。从本质上讲，这些复杂类型都是Object类型。本篇将主要介绍三种Object类型的体现：函数、数组和对象。 函数 函数是JavaScript的一大重点，它非常的灵活。不像C#这种强类型语言，可以显式地声明"class"，JavaScript没有"class"的概念，但...
2016-06-06 07:14:00
94
转载 玩转JavaScript OOP[0]——基础类型
前言 long long ago，大家普遍地认为JavaScript就是做一些网页特效的、处理一些事件的。我身边有一些老顽固的.NET程序员仍然停留在这种认知上，他们觉得没有后端开发肯定是构建不了系统的。 编程语言和技术的结合使用，就像一个男人娶了好几个妞一样。在旧的时代，.NET是大房，JavaScript是偏房。大房是“后宫之主”，不仅要操持家业，还能给你生娃，娃将来也要继承家业的。...
2016-06-04 23:41:00
96
转载 小酌重构系列[25]——终篇总结
前言《小酌重构系列》是我在博客园的第一个系列文章，这个系列历时一个多月终于完成了。完成这个系列后，心里有一些感慨想和大家分享一下。初衷写这个系列的初衷是为了团队培训，为什么要做这个培训呢？是因为在项目的开发过程中，我们遭遇了一些“代码的痛苦”。代码的痛苦写代码是程序员的基本工作，但写出好的代码不是一件容易的事情。写不出好的代码，就可能产生痛苦。代码的痛苦包含哪些方...
2016-06-02 07:17:00
116
转载 小酌重构系列[24]——封装集合
概述当方法返回类型或属性类型为集合时，有些开发者会千篇一律地使用IList<T>集合。然而IList<T>具有集合的所有操作，这意味着调用者不仅可以读取集合信息，还能够修改集合。业务需求本来只是为调用者提供一个可读的集合，例如数据的查询和展示，但当方法返回IList<T>时，无疑隐式地开放了集合可写的权限。此时，我们无法阻止调用者篡改集合元素。...
2016-06-01 07:13:00
105
转载 小酌重构系列[23]——封装条件
概述当条件判断语句较为复杂时（有多个不同的检查项），就像下面这幅图所表示的，会使得代码的可读性会大打折扣，也难以清晰地传达判断意图。再者，当判断逻辑变更时，我们不得不去修改if语句里面的判断代码。如果判断写得有问题，则会影响方法的正确性，也会给该方法的单元测试带来一些障碍。我们可以根据检查项是否需要参数来封装条件，如果检查项不需要参数，则可以将其提取为属性；如果需要参数，...
2016-05-31 22:16:00
98
转载 小酌重构系列[22]——尽快返回
概述阅读文章时，如果某个段落已经传达了关键信息，我们可能就不会逐字逐句地将文章读完，因为我们已经知道了这篇文章的核心内容。与此类似，如果方法中某些条件判断可以得到结果，我们应该尽快返回该结果。尽快返回可以带来三个好处节省阅读代码的时间——如果方法能够尽快返回，后面的代码逻辑可以不必阅读。见下图，如果①已经返回了，就不必阅读②部分的代码避免执行无效的逻辑——如果方法能够...
2016-05-31 07:04:00
98
转载 小酌重构系列[21]——避免双重否定
避免双重否定在自然语言中，双重否定表示肯定。但是在程序中，双重否定会降低代码的可读性，使程序不易理解，容易产生错觉。人通常是用“正向思维”去理解一件事情的，使用双重否定的判断，需要开发者以“逆向思维”的方式去理解它的含义。另外，在写程序时，"!"符号很容易被疏忽和遗漏，一不小心则会编写出错误的代码，从而产生bug。所以，在程序中，我们应当尽量避免使用双重否定。优惠券是否未被使用？...
2016-05-30 22:10:00
159
转载 小酌重构系列[20]——用条件判断代替异常
概述异常处理的关键在于何时处理异常以及如何使用异常，有些开发者会觉得try catch的处理和使用难以把握，于是他们秉承着“您可错杀一千，不可放过一个”的想法，给所有的方法添加try catch。这种方式会对应用程序造成什么影响吗？从用户角度出发，用户确实难以察觉到什么，应用程序运行正常，使用的体验好像也没什么差别。从程序角度出发，大量的try catch会降低代码的可读...
2016-05-21 05:44:00
112
转载 小酌重构系列[19]——分解大括号
概述if else, for, while等是程序中最常用的语句，这些语句有一个共同点——它们的逻辑都封装在一对“{}”包围的代码块中。在实现复杂的业务逻辑时，会较多地用到这些语句，可能会形成多层的代码嵌套。代码的嵌套层数越大，代码的缩进层次就越深，这将会降低代码的可读性。如下图所示，如果我们想理解绿色if代码块的逻辑，需要先了解前3个代码块是如何工作的。N层嵌套的代码不仅可...
2016-05-20 22:59:00
132
转载 小酌重构系列[18]——重命名
概述代码是从命名开始的，我们给类、方法、变量和参数命名，我们也给解决方案、工程、目录命名。在编码时，除了应该遵守编程语言本身的命名规范外，我们应该提供好的命名。好的命名意味着良好的可读性，读你代码的人无需太多的注释，就能通过名称知道它是什么，它能做什么事儿，以及它应该怎么用。我们命名、命名，不断地命名。既然有这么多命名要做，我们不妨做好他。关于命名取名字的成本取个名字...
2016-05-20 07:26:00
110
转载 小酌重构系列[17]——提取工厂类
概述在程序中创建对象，并设置对象的属性，是我们长干的事儿。当创建对象需要大量的重复代码时，代码看起来就不那么优雅了。从类的职责角度出发，业务类既要实现一定的逻辑，还要负责对象的创建，业务类干的事儿也忒多了点。对象创建也是“一件事”，我们可以将“这件事”从业务代码中提取出来，让专门的类去做“这件事”，这个专门的类一般是“工厂类”，这样使得业务类和工厂类各司其职，代码整洁性得以提高。这就...
2016-05-19 23:49:00
100
转载 小酌重构系列[16]——引入契约式设计
概述试想这样一个场景，你提供了一些API给客户端调用，客户端传入了一些参数，然后根据这些参数执行了API逻辑，最终返回一个结果给客户端。在这个场景中，有两个隐患，它们分别是：客户端调用API时，传入的参数是否准确，参数是否满足API的执行前提API逻辑执行完时，返回的结果是否准确，结果是否符合客户端的预期这两个隐患都和“准确性”相关的，API要求（Requir...
2016-05-19 07:15:00
88
转载 小酌重构系列[15]——策略模式代替分支
前言在一些较为复杂的业务中，客户端需要依据条件，执行相应的行为或算法。在实现这些业务时，我们可能会使用较多的分支语句（switch case或if else语句）。使用分支语句，意味着“变化”和“重复”，每个分支条件都代表一个变化，每个分支逻辑都是相似行为或算法的重复。当追加新的条件时，我们需要追加分支语句，并追加相应的行为或算法。上一篇文章“使用多态代替条件判断”中，我们讲到它...
2016-05-17 22:42:00
93
转载 小酌重构系列[14]——使用多态代替条件判断
概述有时候你可能会在条件判断中，根据不同的对象类型（通常是基类的一系列子类，或接口的一系列实现），提供相应的逻辑和算法。当出现大量类型检查和判断时，if else（或switch）语句的体积会比较臃肿，这无疑降低了代码的可读性。另外，if else（或switch）本身就是一个“变化点”，当需要扩展新的对象类型时，我们不得不追加if else（或switch）语句块，以及相应的逻辑，...
2016-05-15 17:08:00
202
转载 小酌重构系列[13]——移除中间类
我们有时候在应用程序中可能编写了一些“幽灵”类，“幽灵”类也叫中间类。这些中间类可能什么事儿都没做，而只是简单地调用了其他的组件。这些中间类没有发挥实际的作用，它们增加了应用程序的层级（layer），并且增加了应用程序的复杂性。这时，我们应将这样的中间类删除，甚至删除中间类所处的“中间层”——这就是本文要讲的重构策略“移除中间类”。移除中间类图说这个重构策略比较容易理解，下面...
2016-05-15 10:32:00
128
转载 小酌重构系列目录汇总
为了方便大家阅读这个系列的文章，我弄了个目录汇总。开篇和结尾开篇有益 (2016-04-23)终篇总结 (2016-06-02)方法、字段重构移动方法 (2016-04-24)提取方法、提取方法对象 (2016-04-26)方法、字段的提升和降低 (2016-05-01)分解方法 (2016-05-02)为布尔方法命名 (2016-05-03)...
2016-05-14 15:32:00
99
转载 小酌重构系列[12]——去除上帝类
关于上帝类神说：“要有光”，就有了光。——《圣经》。上帝要是会写程序，他写的类一定是“上帝类”。程序员不是上帝，不要妄想成为上帝，但程序员可以写出“上帝类”。上帝是唯一的，上帝的光芒照耀人间，上帝是很爱面子的，他知道程序员写了“上帝类”，抢了他的风头，于是他降下神罚要惩戒程序员。——既然你写了“上帝类”，那么就将你流放到艰难地修改和痛苦的维护的炼狱中，在地狱之火中永久地熬炼。你看...
2016-05-14 15:19:00
223
转载 小酌重构系列[11]——提取基类、提取子类、合并子类
概述继承是面向对象中的一个概念，在小酌重构系列[7]——使用委派代替继承这篇文章中，我“父子关系”描述了继承，这是一种比较片面的说法。后来我又在UML类图的6大关系，描述了继承是一种“is a kind of”关系，它更偏向于概念层次，这种解释更契合继承的本质。本篇要讲的3个重构策略提取基类、提取子类、合并子类都是和继承相关的，如果大家对继承的理解已经足够深刻了，这3个策略用起来应该...
2016-05-13 01:28:00
234
转载 小酌重构系列[10]——分离职责
概述“分离职责”是经常使用的一个重构策略，当一个类担任的职责太多时，应按职责将它拆分成多个类，每个类分别承担“单一”的职责，也就是让每个类专心地做“一件事情”。SRP原则在面向对象编程中，SRP原则是一个非常重要的原则（SOLID原则都很重要），在展示示例前，我们先了解一下SRP原则是什么，以及它有什么作用。什么是SRP原则？SRP原则的定义是这样的：Th...
2016-05-12 00:12:00
130
转载 小酌重构系列[9]——分解依赖
概述编写单元测试有助于改善代码的质量，在编写单元测试时，某些功能可能依赖了其他代码（比如调用了其他组件）。通常我们只想测试这些功能本身，而不想测试它所依赖的代码。为什么呢？单元测试的目标是验证该功能是否正确，然而功能所依赖的代码是处于功能范围外的，这些代码可能是一些外部的组件，单元测试无法验证这些外部组件的准确性。单元测试因调用“依赖的代码”出错而失败时，会影响测试结果的判断，我...
2016-05-09 23:31:00
84
转载 小酌重构系列[8]——提取接口
前言世间唯一“不变”的是“变化”本身，这句话同样适用于软件设计和开发。在软件系统中，模块（类、方法）应该依赖于抽象，而不应该依赖于实现。当需求发生“变化”时，如果模块（类、方法）依赖于具体实现，具体实现也需要修改；如果模块（类、方法）依赖于接口，则无需修改现有实现，而是基于接口扩展新的实现。面向实现？面向接口？接口可以被复用，但接口的实现却不一定能被复用。面向实现编程...
2016-05-08 23:09:00
131
转载 UML类图的6大关系
《小酌重构系列》已经完成了大约1/3了，在这些文章中，我使用了一些简单的类图来描述重构策略。在之后的文章中，我可能会借助稍微复杂一些的UML类图来介绍。但是在此之前，我觉得有必要先介绍一下UML类图中6大关系了。这6大关系分别是Inheritance(继承)、Implementation(实现)、Dependency(依赖)、Association(关联)、Aggretation(聚合)...
2016-05-08 13:11:00
237
转载 小酌重构系列[7]——使用委派代替继承
概述子类可以继承父类的字段、属性和方法，使用“继承”可以较大程度地复用代码。在使用继承时，务必要确定代码中定义的“父类”和“子类”确实存在客观的“父子关系”，而不要去做“为了代码复用而使用继承”的事情，这是舍本逐末的做法，也是滥用继承的体现。滥用继承会破坏类之间客观存在的关系，也会模糊代码所体现的语义。使用委派代替继承继承的误区当多个类具有相似的属性、方法时，使其中一个类...
2016-05-07 09:32:00
171
转载 小酌重构系列[6]——引入参数对象
简述如果方法有超过3个以上的参数，调用方法时就会显得冗词赘句。这时将多个参数封装成一个对象，调用方法会显得干净整洁。这就是本文要讲的重构策略“引入参数对象”——将方法的参数封为类，并用这个类的对象替换方法中原有的参数。引入参数对象下图演示了这个重构策略，OrderSerivce表示订单服务，GetOrders()方法根据一些条件获取订单信息。在重构前，GetOrders()方...
2016-05-04 23:58:00
291
转载 小酌重构系列[5]——为布尔方法命名
概述当一个方法包含大量的布尔参数时，方法是很脆弱的，由此还可能会产生两个问题：1. 方法不容易被理解 2. 给方法的使用者造成一定困扰，可能会产生一些预期之外的结果本文要介绍的重构策略“为布尔方法命名”，可以有效地避开这两个问题。为布尔方法命名大量布尔参数带来的问题下图中的SomeClass的SomeMethod包含3个布尔参数，如果没有注释，调用者根本不知道3个...
2016-05-03 22:55:00
141
转载 小酌重构系列[4]——分解方法
概述“分解方法”的思想和前面讲到的“提取方法”、“提取方法对象”基本一致。它是将较大个体的方法不断的拆分，让每个“方法”做单一的事情，从而提高每个方法的可读性和可维护性。分解方法可以看做是“提取方法”的递归版本，它是对方法反复提炼的一种重构策略。分解方法下图表示了这个重构策略，第1次提炼和第2次提炼都采用了“提取方法”这个策略。何时分解方法？“分解方法”最终可以让...
2016-05-02 23:38:00
116
转载 小酌重构系列[3]——方法、字段的提升和降低
本文要介绍的是4种重构策略，它们分别是提升方法、降低方法、提升字段和降低字段。由于这4种重构策略具有一定的相通性，所以我将它们放到一篇来讲解。定义以下是这4种策略的定义提升方法：当子类的方法描述了相同的行为时，应将这样的方法提升到基类。降低方法：在基类中的行为仅和个别子类相关时，应将这样的行为降低到子类。提升字段：当子类中的字段描述着相同的信息时，应将这样的字段提升到基类...
2016-05-01 22:17:00
100
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人