Lostyears的专栏

前两天，看了一篇关于类设计的博客，感触颇深。虽然这篇博客是通篇介绍java类设计的原则，但其精髓和所表达的思想其实无论什么语言都可以适应。很多c++的程序员，虽然写了几年的code，但往往把握不了面向对象的精神所在。这篇介绍类设计原则的博客，其实很多思想都跟设计模式的本质思想融合在了一起。现转此如下：3.2 类设计的基本原则   类是属性和方法（行为）的容器，但它不是垃圾桶，更不能是四像八

"要依赖于抽象，不要依赖于具体。”“要针对接口编程，不要针对实现编程。”陈述：高层模块不应该依赖于低层模块。二者应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。分析：所谓“倒置”是相对于传统的开发方法（例如结构化方法）中总是倾向于让高层模块依赖于低层模块而言的软件结构而言的。高层包含应用程序的策略和业务模型，而低层包含更多的实现细节，平台相关细

“一个对象应该对其他对象有尽可能少的了解”“Only talk to your  immediate friends”“Don’t talk to strangers”“每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位”  ……来源：迪米特法则(LoD)最初是用来作为面向对象的系统设计风格的一种法则，是很多著名系统，如火星

“要尽量使用合成/聚合，尽量不要使用继承。”陈述：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新对象通过向这些对象的委派达到复用已有功能的目的。引入：如我们所知，在面向对象设计里，不同环境中复用已有设计和实现的基本方法：继承。合成/聚合。1、继承复用继承复用通过扩展一个已有对象的实现来得到新的功能，基类明显地捕获共同的属性和

“使用多个专门的接口比使用单一的总接口要好”。“一个类对另外一个类的依赖性应该建立在最小的接口上”。陈述：不应该强迫客户依赖于他们不用的方法。一个类的不内聚的“胖接口”应该被分解成多组方法，每一组方法都服务于一组不同的客户程序。例子： Door可以加锁、解锁、而且可以感知自己是开还是关； Door是抽象基类，客户程序可以依赖于抽象而不是具体的实现。

“一个软件实体如果使用的是一个基类的话，一定适用于其子类，而且根本不能觉察出基类对象和子类对象的区别。”陈述：子类型（Subtype）必须能够替换他们的基类型(Basetype)Barbara Liskov对原则的陈述：若对每个类型S的对象o1,都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P的行为功能不变，则S是T的子类型。通俗地讲

设计一个模块时，应当使该模块在不被修改的前提下被扩展，即可在不必修改源代码的情况下改变该模块的行为。 陈述： 软件实体（类、模块、函数等）应该是可以扩展的，同时还可以是不必修改的，更确切的说，函数实体应该：（1）对扩展是开放的当应用的需求变化时，我们可以对模块进行扩展，使其具有满足改变的新的行为。即：我们可以改变模块的功能（2）对更改是封闭的对模块进行扩展时，不必改动模块已

陈述：就一个类而言，应该只有一个导致其变化的原因分析：一个职责就是一个变化的轴线。一个类如果承担的职责过多，就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力。多职责将导致脆弱性的臭味。示例1：  Rectangle类具有两个职责：计算矩形面积的数学模型将矩形在一个图形设备上描述出来Rectangle

6.2  多重继承的常见误用既然面向对象设计中多重继承的误用如此广泛，那么就有必要调查一下误用的原因，并且看一下为何这么危险。让我们假定我们有3个类：翅膀、机身、驾驶舱。我们想要构建一个飞机类。我们可以让飞机类继承翅膀、机身、驾驶舱，也可以包含它们。因为翅膀是用铝和铆钉做的，我们可以扩展我们的设计来包含它们（见图6.1）。 图6.1  设计飞机的两种方法

作者 张洋 | 发布于 2011-10-18分布式 一致性哈希摘要本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。分布式缓存问