一直谈软件设计，却不能准确的描述。结合最近看《黑客与画家》，这才对设计的六大原则有了一点浅显的体会。首先说一下一个项目的路径：开发、重构、测试、投产、运维。其中重构的好处就是希望对原有设计和代码进行修改（注意：重构的应该分两个方向：设计上的修改和代码上的修改），而运维则是希望尽量减少对原有代码的修改，保持历史代码的纯净，提高系统稳定性。 原则一：开闭原则（OCP）  软件应该保持对扩展开放，对修改

DDD: 领域驱动模型 OOD: 面向对象的设计。 测试驱动开发TDD TDD主要通过单元测试进行。在编写功能代码前，先编写单元测试代码。

单一职责原则(SRP)已经几乎是每一个程序员都知道的设计原则。最早由Robert C. Martin在<<敏捷软件开发 — 原则、模式与实践>>中正式提出。书中作者在结论中提到:   SRP是所有设计原则最简单的，但也是最难运用的。（中文翻译有之一，略去了) 现实工作中，关于一个类是否符合SRP，或者是否有必要符合SRP的讨论是经常发生的。争论的关键在于职责的定义，但我理解SRP真正的核心是关注于

背景 世界上电源插头标准很多, 这里只说国标和英标: 中国标准: 英国标准: 各地插头标准不同带来的另一个问题是各地的标准插座主要针对当地插头设计。 常在世界各地跑的朋友都知道一定要配个转接头, 比如这个: 这个转换头名称是World Travel Adapter, 所起的作用就是适配。（严格来说，上面的转接头还应用了工作方法。） *另一种形式是由插座提供适配，作用是一样的。 在软件领域里，我们也

背景 正如电脑主机和显示器之间，主机的配置千变万化，不断升级，显示器可能升级缓慢。如果这时你买的是一体机，硬件升级就要受到限制。这就是一个典型的分离变化的需求场景。 在应用中,一个业务会有多个协作者，直接耦合会导致其中一个类的变化就会影响其它类的行为。这时最好的做法是对行为进行抽象，区分出变与不变，或者核心与外围的部分，然后定义出接口来隔离变化。 以Chromium的主文档加载为例。FrameLo

先整个OOD的模型 其中如何得到领域模型？ 事务模式：事务模式强调以“事务”为中心，串起跟事务相关的事务明细，参与者，地点，物品。 通过事务模式，快速理解领域模型，得到大致的类图。 通过用例描述与用例图，可以进一步由业务建模(业务规则）细化类图。 序列图关联了类图与用例图两方面，可通过BCE确定序列图。 BCE模式，将对象分为三类：边界类（boundary class），控制类（control c

关于OOD中的里氏替换原则，大家耳熟能祥了，不再展开，可以参考设计模式的六大设计原则之里氏替换原则。这里尝试讨论常常违反的两种形式和解决方案。 违反里氏替换原则的根源是对子类及父类关系不明确。我们在设计继承关系常常受一些主观认识的左右，比如Robert C. Martin提到的线段与线的关系，以及被大家说到烂的正方形与矩形。从以前的经验我们认为它们符合继承关系，比如线段是线的较短形式，正方形是矩形

设计模式-OOD的设计原则(1)-"开-闭原则" 设计模式-OOD的设计原则(2)-"里氏代换原则" 设计模式-OOD的设计原则(3)-"依赖倒转原则" 设计模式-OOD的设计原则(4)-"接口隔离原则" 设计模式-OOD的设计原则(5)-"合成聚合复用原则" Liskov替换原则（LSP）-Barbara Liskov :若对每个类型S的对象o1，都存在一个类型T的对象o2，使得在所有针对T

律师与委托人 (Attorney-Client) 目的 控制访问类实现细节的粒度。 动机 C++中的friend会开始类内部的所有细节，也因此破坏了封装性。C++没有提供可以选择性使用某一部分私有成员的方式，要么全部开放，要么全部拒绝。例如下面例子中的类Foo声明Bar为其友元，可以访问它的所有私有成员。这样增加了耦合性，类Bar也无法单独发布，这样并不太合适。 class Foo { priva

内部类 (Inner Class) 目的 不用通过多重继承就可以实现多套接口,同时可以自然地向上转换(Up-casting)。 在单个抽象下提供相同接口的多个实现。 别名 动机 两个独立类库通过不同的接口提供的虚函数签名可能冲突，如果这时需要同时实现这两个函数就会出现问题。示例如下: class Base1 /// 来自月球 { public: virtual int open

目的 达到延迟拷贝(lazy copy)的优化目的。和延迟初始化(lazy initialization)相似, 选择在恰当的时机更加有效。 别名 COW (copy-on-write) Lazy copy 动机 拷贝对象有时会带来性能损失(performance penalty)。如果对象经常拷来拷去，但以很少修改，copy-on-write就能明显地提升性能。为了实现copy-on-write

现在有许多设计原则，但是最基本的，就是SOLID（缩写），这五项原则。  S  = 单一责任原则 O = 开闭原则 L  = Liscov替换原则 I  = 接口隔离原则 D = 依赖倒置原则 1.单一责任原则（SRP 原则）： 它的意思是：“如果你可以在一个设备中实现所有的功能，你却不能这样做”。为什么呢？因为从长远来看它增加了很多的可管理性问题。 从面向对象角度解释是："导致类变化的因素永远不

OOD基本上有6大原则，而实际上都是互补的，也就是说一些原则需要利用另一些原则来实现自己。6大原则如下： 1) Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。 2) Liskov Substi

OOD 面向对象设计有很大的几率出现在小公司的面试上，在youtube上找了一个很好的教程来和大家分享一下。 问题： OOD 思想设计两人投掷硬币的游戏。 步骤一： 准备documentation 游戏介绍：随机选择一个玩家，令该玩家预测硬币的正反面，另一个玩家获得和第一个玩家相反的选项。开始投掷硬币，预测正确的赢。 Actors： 1. 玩家A 2. 玩家B  3. 硬币  4. 掷硬币游戏 根

本文译至：http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod 什么是面向对象的设计？这是怎么一回事呢？它的好处是什么？它的成本又是什么？在几乎所有的软件开发人员正在使用某种类型的面向对象的语言的时代，问这些问题可能看起来很可笑。但是这个问题很重要，因为，在我看来，我们中的大多数人不知道为什么使用这些语言，也不知道如何从中获得最大的好处。

OO原则 前言：设计时需要考虑这些原则，但随意使用这些原则会使你的程序出现不必要的复杂性（Needless Complexity）。 参考及说明 本文的撰写，是基于阅读后的梳理 《Agile Software Development：Principles,Patterns.and.Practices 》 1. 开放-封闭原则（Open-Closed Principle） 简称OCP。 （一）概念：

一、概述 面向对象有七大设计原则：单一职责原则、开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则。 最主要的是：SOLID        S：单一职责原则        O:开闭原则        L: 里氏替换原则        I:接口隔离原则       D:依赖倒转原则 二、面向对象设计原则 1、单一职责原则 上面这个图，有趣地反映了单一职责的重要性，如果我们做

1. 名词介绍 OOD，面向对象设计 DIP，依赖倒置（软件设计原则） IOC，控制反转（软件设计模式） DI，依赖注入 IOC Container，控制反转容器，也是依赖注入容器 2. 组成部分 服务清单（功能清单，service list） 服务（高层类，service ，对外提供服务） 服务提供者（底层类，service provider ，实际提供服务的对象） 2. 依赖倒置原则(DIP)

我一直在网上搜索一段时间。我正在寻找OOD实践的小样本练习(以及一些内部TDD研讨会)。 如果有一个单一的地方，这个需求正在被服务，请指出它..并关闭这个问题 约束： 语言不可知现实世界的问题 >小：最大需要一个小时到两个的东西来解决(或者具有可以适应此约束的子部件)。 不以算法为中心：不要仅仅局限于解决计算任务。 (有多个站点服务于此类别。)涉及> 2个互动实体。 >由多人解决，最好是自己：善良