上一篇博文《BAT解密：互联网技术发展之路（6）- 服务层技术剖析》中，介绍了互联网业务发展特点的中的“复杂性”的应对方式，本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化，提到高可用时第一反应就是双机或者备份，但是对于互联网这种超大容量和访问量的业务来说，这两个手段都是雕虫小技，无法应对互联网业务的高性能和高可用需求，互联网业务的高可用和高性能 ...继续阅读 (3)

在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，当系统的数量增加到一定的程度，就由复杂度量变带来了复杂度的质变，主要体现在系统间相互依赖程度加深：比如说为了完成A业务系统，可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估，可以发现系统间的依赖是指数级增长的，例如3个系统相互关联的路径为3条，6个系统相互关联的路径为15条。服务层的主要目标，其实就是为了降低系统间相互关联的复杂度。1. 配置中心配置中心故名思议，就是集中管理各个系统的配置。当系统数量不多的时候，我们一般采取各系统自己管理自己的配置，但系统数量多了以后，这样的处理方式有以下的问题：1）某个功能上线的时候，要多个系统配合一起上线，分散配置的时候，配置检查、沟通协调需要耗费较多时间；2）处理线上问题的时候，需要多个系统配合查询相关信息，分散配置的时候，操作效率很低，沟通协调也需要耗费较多时间；3）各系统自己管理配置的时候，一般是通过文本编辑的方式修改，没有自动的校验机制，容易配置错误，而且很难发现。例如：我们曾经遇到将IP地址的数字0误敲成了键盘的字母O，肉眼非常难发现，但程序检查其实就很容易；实现配置中心主要就是为了解决以上这些问题，将配置中心做成通用的系统有如下的好处：1 ...继续阅读 (35)

在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，当系统的数量增加到一定的程度，就由复杂度量变带来了复杂度的质变，主要体现在系统间相互依赖程度加深：比如说为了完成A业务系统，可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估，可以发现系统间的依赖是指数级 ...继续阅读

BAT解密：互联网技术发展之路（5）- 开发层技术剖析1. 开发框架在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术，将会带来很多问题，典型的问题有：1）技术人员之间没有共同的技术语言，交流合作少2）每类技术都需要投入大量的人力和资源和熟练精通3）不同团队之间人员无法快速流动，人力资源不能高效的利用所以，互联网公司都会指定一个大的技术方向，然后使用统一的开发框架，例如Java相关的开发框架SSH、SpringMVC、Play，Ruby的Ruby on Rails，PHP的ThinkPHP，Python的Django等等。使用统一的开发框架能够解决上面提到的各种问题，大大提升组织和团队的开发效率。对于框架的选择，有一个总的原则：优选成熟的框架，避免盲目追逐新技术！为什么呢？首先，成熟的框架资料文档齐备，各种坑基本上都有人踩过了，遇到问题很容易通过搜索解决其次，成熟的框架受众更广，招聘时更加容易招聘到合适的人才第三，成熟的框架更加稳定，不会出现大的变动，适合长期发展以我亲身经历的一个反例为例：我们使用了Play 1作为Java开发框架，因为它是轻量级的Java开发框架，但没想到Play 2直接改为 ...继续阅读 (15)

BAT解密：互联网技术发展之路（4）- 存储层技术剖析1. SQL即关系数据。前几年NoSQL火了一阵子，很多人都理解为NoSQL是完全抛弃关系数据，全部采用非关系型数据，但事实经过几年的试验后，大家发现关系数据不可能完全抛弃，NoSQL不是No SQL，而是Not Only SQL，即NoSQL是SQL的补充。所以互联网行业也必须依赖关系数据，考虑到Oracle太贵，还需要专人维护，一般情况下互联网行业都是用MySQL、PostgreSQL这类开源数据库。这类数据库的特点是开源免费，拿来就用；但缺点是性能相比商业数据库要差较多。随着互联网业务的发展，性能要求越来越高，必然要面对一个问题：将数据拆分到多个数据库实例才能满足业务的性能需求（其实Oracle也一样，只是时间早晚的问题）。数据库拆分满足了性能的要求，但带来了复杂度的问题：数据如何拆分、数据如何组合。这个复杂度的问题解决起来并不是那么容易，如果每个业务都去实现一遍，重复造轮子将导致投入浪费、效率降低，业务开发想快都快不起来。所以互联网公司流行的做法是发展到一定阶段后，就会将这部分功能独立成中间件，例如百度的DBProxy、淘宝的TDDL。不过这部分的要求很高，将分库分表做到自动化和平台化，不是一件容易的事情，所以一般是很牛逼的公司才会做。典型的有：百度的DBProxy、淘宝TDDL如下是淘宝TDDL的结构图：2. NoSQ ...继续阅读 (22)

大部分人对于BAT的技术有一种莫名的崇拜感，觉得只有非常牛逼和天才才能做出现在的这些系统，但经过前面两篇博文的分析，我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面，而是业务的不断发展推动技术的不断发展，一步一个脚印，持续几年甚至10几年的发展，才能达到当前技术复杂度、先进性、牛逼度。抛开BAT各自差异很大的业务，站在技术的角度来看，其实BAT的技术架构基本是一样的，再将视角放大，你会发现整个互联网行业的技术发展，最后都是殊途同归。如果你正处于一个创业公司，或者正在成为另一个BAT的路上而拼搏，那么深入理解这种技术模式（或者叫技术结构、技术架构），对于自己的发展、公司的发展都大有裨益，你将不会再迷茫，你也不再会心里打鼓，CTO将对你刮目相看，CEO将奉你为神明 ：）闲话不多说，有图有真相，看看互联网的标准技术架构是什么样子：上面这张图基本上一网打尽了互联网技术公司的技术点，不同的公司只是在具体的技术实现上稍有差异，但不会跳出这个框架的范畴。接下来的博文里，我将逐一介绍每个技术点，包括为什么会有这些技术点，这些技术点的主要场景是什么，这些技术点将如何发展。================================================================================转载请注明出处：BAT解密：互联网技术发展之路（3）- 牛逼公司 ...继续阅读 (16)

BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展在《互联网技术发展之路（1） - 技术发展的驱动力》一文中，我们详细阐述了对于服务类的业务来说，业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。互联网业务千差万别，但由于他们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。不同时期的差别主要体现在两个方面：复杂性、用户规模。复杂性业务的发展第一个主要方向就是“业务越来越复杂”，我们来看看不同时期业务的复杂性的表现。【初创期】互联网业务刚开始一般都是一个创新的业务点，这个业务点的重点不在于“完善”，而在于“创新”，只有创新才能吸引用户；而且因为其“新”的特点，其实一开始是不可能很完善的。只有随着越来越多的用户的使用，通过快速迭代试错、用户的反馈等手段，不断的在实践中去完善，去继续创新。初创期的业务对技术就1个要求：“快”，但这个时候却又是创业团队最弱小的时候，可能就那么几个技术人员，所以这个时候十八般武艺都需要用上：能买就买，有开源的就用开源的，能模仿的就模仿，甚至可能是能偷就偷。继续以淘宝和QQ为例：第一版的淘宝（http://www.yixieshi.com/it/20770.html ）：第一版QQ（http://www.yixieshi.com/it/20770. ...继续阅读 (16)

BAT解密：互联网技术发展之路（1） - 技术发展的驱动力互联网行业是一个快速发展、快速变化的行业，新的业务、新的机会层出不穷，新的技术如雨后春笋般冒出，NoSQL、大数据、云、Node.js、Docker等，无时不刻都在轰炸程序员们的脑袋，难怪中国的程序员都流传一个说法：过了30岁不能做技术工作了，因为技术发展太快了！快节奏带来机会，但对于技术人员来说，更多的是带来挑战，甚至有时候是困惑。例如：1）Docker很火哦，咱们要不要用呢 ？2）Node.js好牛逼啊，我们用上就更牛逼了......3）大数据和云是业界发展趋势，我觉得我们也应该跟上技术发展的趋势............还有很多类似的问题和想法，其实归根结底可以归纳为一个统一的问题：是什么推动了一个互联网企业的技术发展？关于这个问题的回答，基本上可以分为几个典型的派别：1）潮流派潮流派的典型特征就是对于新技术特别热衷，紧跟技术潮流，当有新的技术出现时，迫切的想将新的技术应用到自己的产品中。例如：NoSQL很火，咱们要大规模的切换为NoSQL；大数据好牛逼呀，将我们的MySQL切换为Hadoop吧；Node.js是的javascript统一前后端，这样非常有助于我们工作的开展；......等等2）保守派保守派的典型特征和潮流派正好相反，对于新技术抱有很强的戒备心，稳定压倒一切，已经掌握了某种技术，就一直用这种技术打天下。就 ...继续阅读 (19)

JDBC当使用INSERT INTO....VALUES()语句批量插入的时候，应该使用JDBC的PreparedStatement的批量操作方法，而不是采用一条一条执行的方法。例如（来源：http://superjavason.iteye.com/blog/255423）：如上图，代码有3个关键的处理步骤：1）关闭自动提交2）addBatch3）executeBatch使用这种方法，SQLite测试时的效果提升非常明显，从 10000/s提升到100000/s（数据仅做参考，不能作为决策依据）需要注意的是：这种方式只适合相同结构的SQL语句批量执行，对于不同结构的SQL语句不能用这种方式，因为PreparedStatement在初始化的时候要指定sqlMySQL使用上述参数后，MySQL的性能也有一定的提升，但提升不明显。经过查找，确认和如下两个参数有关：rewriteBatchedStatements=truemysql默认关闭了batch处理， 通过此参数进行打开， 这个参数可以重写向 数据库提交的SQL语句useServerPrepStmts=false如果不开启(useServerPrepStmts=false)， 使用com.mysql.jdbc.PreparedStatement进行本地SQL拼装， 最后送到db上就是已经替换了?后的最终SQL经过测试，打开这2个参数 ...继续阅读 (26)

这两天协助运维定位1个监控程序CPU占用率达到150%的问题，过程曲折，结论简单，很有意思：）首先我们来看一下cpu高时候截图：可以看到红色框中的监控程序CPU占用率都很高，但其实这些监控程序的实现很简单：发送1个http请求，收到响应后简单判断一下响应码，然后打印监控结果，打印完成就退出了。每次监控都会重新由daemon程序拉起运行。这么简单的业务占用这么高的cpu，怎么感觉都不太可能，于是拿到监控程序的源码开始定位。第一个想到的是VisualVm、JConsole等工具，但由于程序很快就运行完成了，这两个工具都还没有连接上就结束了，而且拿到的数据也没法看出具体是什么原因导致cpu高，尝试了一下就放弃了。第二个尝试是用strace去跟踪程序的调用，结果摘录如下（省略很多）：17572 14:08:43.552199 futex(0x580497a4, FUTEX_WAIT_PRIVATE, 1, {0, 9949000}) = -1 ETIMEDOUT (Connection timed out) 17572 14:08:43.562857 futex(0x58049028, FUTEX_WAKE_PRIVATE, 1) = 0 17572 14:08:43.563029 clock_gettime(CLOCK_REALTIME, {1423721323, 563056000}) ...继续阅读 (138)

最近因为某个业务需要用到CRC32算法，但业务又不能容忍重复的数值出现，于是自然就想了解一下CRC32算法的冲突概率（或者叫碰撞概率）。本以为这种问题应该很多人分析过，结果找来找去就只看到一大堆数学公式，我这种数学盲完全看不懂。好不容易找到一张图，但看得云里雾里（原图链接：http://preshing.com/20110504/hash-collision-probabilities/ ）：既然网上的不靠谱，那就自己来验证吧，写个php脚本很简单，我的第1次验证模型是这样的：取1个整型值作为初始值，然后递增1000W次，每次计算crc32的值，输出到文件，再使用sort crc32.result | uniq -c -d > crc32-collision.txt 来输出冲突的结果结果出来，我大吃一惊：1000W没有1个冲突！大大出乎意料，于是尝试2000W，还是没有冲突！！ 于是尝试 1亿，这回有冲突了，冲突数大约是240W个！！虽然我没有看懂crc32算法的原理，但隐约觉得这个冲突率不符合实际，于是继续寻找，终于功夫不负有心人，找到一个详细和完整的测试报告（http://www.backplane.com/matt/crc64.html）：CRC16 - CRC64 test results on 18.2M dataset结果摘要如下：Summary, 18.2 milli ...继续阅读 (187)

浓缩10年工作经历精华，结合电信领域和互联网领域的经验，剥去架构设计高大上的神秘外衣，提炼架构设计的终极大法，菜鸟也能做架构设计，架构设计不过如此。主要内容包括：1）什么是架构设计2）架构设计的终极大法3）架构设计的基本原则4）如何提升架构设计能力详细请点击下载：十年磨一剑之架构设计 ...继续阅读 (52)

零缺陷开发技巧，简单易懂，一学即会，一用就有效果，让你写10K代码只有1个bug的方法个人实践效果：10K代码1个bug, 个人负责的70%的版本0 bug详细请点击下载：零缺陷”开发技巧内容简介：1个原则：2/8原则2个技巧：防御性编程、代码写三遍3个条件：熟悉编程语言、单元测试、熟悉业务 ...继续阅读 (33)

原文链接：专访李运华：程序员如何在技术上提升自己专访李运华：程序员如何在技术上提升自己发表于2014-10-29 09:48|18625次阅读| 来源CSDN|95条评论| 作者钱曙光社区之星访谈李运华程序员面向对象团队管理摘要：社区之星第56期采访了UC的软件工程师李运华，他先后经历了电信行业和互联网行业。在本次采访中，李老师分享了他的职场经历、团队管理经验、程序员提升自己的方法和应具备的素养，以及谈了对面向对象和编程语言看法。李运华（博客），专注于Linux、MySQL、开源技术、系统分析、架构设计，有丰富的需求分析、系统设计、编程的经验，热爱技术但不拘泥于技术。喜欢挑战，从各方面不断提升自己。CSDN：请和大家介绍下你和目前所从事的工作。李运华：大家好，我是来自UC的软件工程师，已经在软件领域摸爬滚打10年了，先后经历了电信行业和互联网行业。毕业后首先是去了华为，做核心网的系统开发，做过软件工程师、系统分析师；后来换到现在所在的UC，先后做过技术研究、基础平台开发、社区系统，现在在九游游戏中心担任项目leader。虽然说是leader，但其实管理和开发的时间是3/7比例，所以至今其实还是个“码农”。非常爱好技术，“精通”后端开发技术（C++、Java、Linux、MySQL等），目前正在学习前端，力争成为FSE；虽然很爱好技术，但并不局限于只在技术上提升自己，管理技能、综合技 ...继续阅读 (22)

说到tcp协议，凡是稍微看过的人都能顺口说出三次握手和四次断连，再牛逼的一点的就能够把每个状态（SYNC_SENT、CLOSE_WAIT。。。。。。等）都能背出来，而说道socket编程，基本上写过网络编程的人都会熟悉那几个标准的API：socket、connect、listen、accept。。。。。。等但是，我敢打赌很少有人明白tcp状态和socket编程API之间的关系。不信？ 看看如下几个问题你是否知道吧：1）什么时候客户端才能够连接上server端， 是server端调用bind后还是listen后还是accept后 ？2）什么情况下会出现FIN_WAIT_2状态。。。。。。。。。。。。。。。。。。。。。本周打破砂锅问到底的精神以及实事求是的精神，我用python脚本写了一些脚本测试这些情况，看完后你一定会大呼过瘾，对tcp的协议和socket编程的理解又更上层楼。注：以下测试是在Linux（2.6.18）平台上用python（2.7）脚本测试，其它平台没有测试，有兴趣可以自己测试一下。【连接过程测试和验证】第1种情况：client调用connect，server只是调用了socket + bind，没有调用listentcpdump抓包如下：抓包结果显示：server端直接回复了RST包此时使用netstat或者ss命令去查看，无论是client还是server，都查不 ...继续阅读 (43)

终于到了要结束的时候了，感谢那些一路关注和跟随的朋友们，面向对象葵花宝典系列的博文到这里就要结束了。本系列的博文只是我个人写作的面向对象葵花宝典的摘录，面向对象葵花宝典的全文请下载PDF，里面的内容更全、阅读更方便。如果你是新手，这里有详尽和通俗易懂的概念和方法介绍，让你能够快速入门如果你是老手，这里有完整的面向对象开发流程，让你能够得心应手，精益求精如果你是高手，这里有独树一帜的理论解读，让你大开眼界CSDN下载链接（点击下载）：面向对象葵花宝典：思想、技巧与实践 - 完整版【一点小小的倡议】如果觉得本博客系列或者PDF对你有帮助，想略表心意的话，可以向 @免费午餐 捐一顿午餐（RMB 3元）http://weibo.com/freelunch?topnav=1&wvr;=6&topsug;=1 ...继续阅读 (106)

掌握了设计模式之道后，我们将以全新的方法来理解设计模式，这个方法更简单、更直观，不信？看几个样例就知道了=====================================================================DECORATOR模式（以设计模式之道来理解）【业务】假设你进入了一个信息安全管理非常严格的公司，这家公司不允许员工自行打印文档，所有的文档打印都需要交给文档打印系统统一管理。文档打印系统会记录每次打印的时间、内容、打印人员。。。。。。等等，以便后续出现问题的时候进行追查。由于公司有很多的部门，每个部门的安全要求并不完全一样，同时每个部门关于文档打印也有自己的一些规定。我们的任务就是要开发一套能够支持整个公司文档打印需求的系统。【发现变化】文档打印系统面对的变化主要体现在：文档打印要求是变化的，不同的部门有不同的要求，同一个部门也可能修改自己的打印需求。例如：A部门是一个战略规划的部门，里面的资料都非常重要，打印的时候需要在页眉位置打印“绝密”，在页脚的位置打印“密级申明”，同时要加上“绝密文档”的水印；B部门是内部培训部门，打印培训材料的时候需要在页眉位置打印“内部公开”，但不需要密级申明，同时加上“培训资料”的水印C部门是对外宣传部门，打印宣传材料的时候只需要加上“公司logo”的水印；【传统方法】传统方法使用类继承来封装打印请求，为每个部 ...继续阅读 (26)

又是设计原则，又是设计模式，到底该用哪个呢？ =============================================================================在“设计模型”一章中，我们提到设计原则和设计模式是互补的，设计原则和设计模式互补体现在：设计原则主要用于指导“类的定义”的设计，而设计模式主要用于指导“类的行为”的设计。举一个很简单的例子：假设我们要设计一个图形类Shape，这个类既支持三角形，又支持矩形，其代码如下：package com.oo.designpattern.diagram; /** * 设计不好的Shape类，同时兼顾三角形和矩形的职责，不符合SRP设计原则 * */ public class BadShape { //三角形的属性 Position a; Position b; Position c; //矩形的属性 Position m; int length; int width; public void drawTriangle(){ //TODO: 画出三角形 } public void drawRectangle(){ //TODO: 画出矩形 ...继续阅读 (19)

很多人能够熟练背诵出所有的设计模式，能够快速画出各种设计模式的UML类图，也能够熟练的写出《设计模式》一书中各个模式的样例代码。但一到实际的项目设计和开发的时候，往往都会陷入迷茫：要么无从下手，不知道哪个地方要用设计模式；要么生搬硬套，胡乱使用设计模式，将方案和代码搞得一团乱麻。===========================================================================【知易行难 —— 设计模式应用的问题】形而下者谓之器，形而上者谓之道。---《易经·系辞》正如很多流行的技术（面向对象、UML等）一样，几乎大部分人都会宣称自己“掌握、熟练掌握”，甚至“精通”，然而，真正掌握的或者精通的，实在是少之又少。一种典型的现象是：很多人能够熟练背诵出所有的设计模式，能够快速画出各种设计模式的UML类图，也能够熟练的写出《设计模式》一书中各个模式的样例代码。但一到实际的项目设计和开发的时候，往往都会陷入迷茫：要么无从下手，不知道哪个地方要用设计模式；要么生搬硬套，胡乱使用设计模式，将方案和代码搞得一团乱麻。这是什么原因呢，难道是设计模式不好用，或者设计模式根本就是一个噱头？答案不在于设计模式本身是否有用，而是在于我们没有掌握正确的学习和应用设计模式的方法。学习《设计模式》一书中的23个设计模式，只是掌握了《设计模式》的“器”，但并没有掌 ...继续阅读 (23)

“设计模式”这个词几乎成为了软件设计的代名词，很多人非常天真的以为掌握了设计模式就掌握了软件设计，但实际上如果只是握了设计模式，软件设计的门都还没摸到！========================================================谈起设计模式，那是几乎无人不知，无人不晓，大名鼎鼎的“GOF”（中文有的翻译为“四人帮”）惊世之作，真是“平生不识GOF，学尽设计也枉然！”然而，设计模式真的是软件设计的“瑞士军刀”，切、削、锯、钻样样精通么？读过设计模式的朋友估计不少，但真正注意过《设计模式》的副标题的估计很少，而这个副标题却是避免误解设计模式的关键。《设计模式》的副标题是：可复用面向对象软件的基础！不要小看了这短短的一句话，如果你没有看这句话，或者只是一扫而过并没有仔细体会，那么你很可能就认为设计模式是一把“瑞士军刀”，能够解决所有的设计问题，而实际上“设计模式只是一把锤子”，有个谚语叫做“如果你手里有一把锤子，那么所有的问题都变成了钉子”，如果你拿着设计模式这把锤子倒出去敲，要么东西被敲坏，要么就不起作用。为什么说设计模式只是一把锤子呢？我们还是从副标题来看。《设计模式》的副标题揭示了《设计模式》的两个主要约束：1）设计模式解决的是“可复用”的设计问题；2）设计模式应用的领域是“面向对象”；相信经过我这么一提醒，大家基本上都能够明白了为什么“设计模式 ...继续阅读 (25)

经过前面深入的阐述，SOLID的原则我们已经基本上讲清楚了，但如果想熟练的应用SOLID原则，仅仅知道SOLID是什么（what）还不够，我们还需要知道SOLID原则在什么时候和什么场景应用（when或where）。幸运的是，SOLID原则的5个独立原则在实际应用中基本上都是独挡一面，并不会在某个地方需要同时从可选的几个原则中挑选一个最优的原则来应用，这样大大降低了我们应用SOLID原则的难度。SOLID原则具体的应用场景如下：SRP原则：用于类的设计当我们想出一个类，或者设计出一个类的原型后，使用SRP原则核对一下类的设计是否符合SRP要求。OCP原则：总的指导思想OCP原则是一个总的指导思想，在面向对象的设计中，如果能够符合LSP/ISP/DIP原则，一般情况下就能够符合OCP原则了。除了在面向对象的软件设计中外，OCP也可以用于指导系统架构设计，例如常见的CORBA、COM协议，其实都可以认为是OCP原则的具体应用和实现。LSP原则：用于指导类继承的设计当我们设计类之间的继承关系时，使用LSP原则来判断这种继承关系是否符合LSP要求。ISP原则：用于指导接口的设计ISP原则可以认为是SRP原则的一个变种，本质上和SRP的思想是一样。SRP用于指导类的设计，而ISP用于指导接口的设计。DIP原则：用于指导类依赖的设计当我们设计类之间的依赖关系时，可以使用DIP原则来判断这种依赖 ...继续阅读 (30)

NOP，No Overdesign Priciple，不要过度设计原则。这应该是你第一次看到这个原则，而且你也不用上网查了，因为这个不是大师们创造的，而是我创造的：）之所以提出这个原则，是我自己吃过苦头，也在工作中见很多人吃过类似的苦头。你可能也见过这样的场景：产品提出了一个需求，设计师眼光非常长远，他甚至把5年后可能的业务变化都提出来并且加以设计了，让你不得不佩服设计师的高瞻远瞩的眼光，并且由衷的从心底赞叹：牛逼啊！但很快你就会发现，设计师是很牛逼，但你开发的时候就很苦逼了，设计方案巨复杂，工作量巨大，即使你发扬一不怕苦二不怕累的精神，每天加班加点奋斗了三个月终于做出来了，但你苦逼完了，测试跟着苦逼了：很多东西测试都没办法测试！怎么会出现这样的情况呢？我们做面向对象不就是为了应对变化、拥抱变化么？要回答这个问题其实很简单，孔夫子在《论语》中已经为我们解答了：“子贡问：‘师与商也孰贤？’子曰：‘师也过，商也不及。’曰：‘然则师愈与？’子曰：‘过犹不及。’”什么事情过头了就和没有达到是一样的效果，面向对象的设计也不例外。面向对象的初衷虽然是为了拥抱变化，但这个变化也是有一个度的，而不是预测得越长越好，原因很简单：预测越长，预测的结果正确性越低！谁能在2000年预测SUN公司的衰落？谁又能在2005年预测苹果的崛起？除了预测时间越长准确性越差的问题外，过分设计会导致设计方案不必要的复杂 ...继续阅读 (26)

DIP，dependency inversion principle，中文翻译为“依赖倒置原则”。DIP是大名鼎鼎的Martin大师提出来的，他在1996 5月的C++ Reporter发表“ The Dependency Inversion Principle”的文章详细阐述了DIP原则，并且在他的经典著作《 Agile Software Development, Principles, Patterns》（中文翻译为：敏捷软件开发：原则、模式与实践）、《Practices, and Agile Principles, Patterns, and Practices in C#》（中文翻译为：敏捷软件开发：原则、模式与实践（C#版））中详细解释了DIP原则。DIP原则主要有两点含义：1） 高层模块不应该直接依赖低层模块，两者都应该依赖抽象层；2） 抽象不能依赖细节，细节必须依赖抽象；虽然DIP原则的解释非常清楚，但要真正理解也不那么简单，因为有几个关键的术语都比较抽象，我们需要更详细的解析：1）什么是模块？英文中用到了module、component，但我们这是在讲类的设计原则，为什么要把DIP拉进来呢？其实Martin大师只是讲一个设计原则而已，这个原则可以应用到软件系统不同的层级。例如：站在架构层的角度，模块可以指子系统subsystem站在子系统的角度，模块可以指modul ...继续阅读 (25)