摘要：使用Specialized Types的好处：可以服用：验证、计算。更高的编程层次。容易在UI层封装组件。 阅读全文

摘要：背景最初接触《彩色UML》的时候就给了我很大的触动，可惜一致没有内化这种触动，直到最近一次看“老大”画了一个彩色的分析图，又突然的重现了这种触动，然后在一个梦里内化了这种冲动，第二天发现团队的“贴纸”和“水笔”都是不同的颜色。彩色UML第一次主动的利用颜色备注合理的利用色彩，编程人生更精彩。 阅读全文

摘要：情况是这样的第一步：你学会了面向接口编程。第二步：如何实例化接口呢？你学会了工厂。第三步：你学会了万能的工厂：IOC。第四步：IOC 容器都提倡依赖注入，因此你也学会了。第五步：无状态的类型的生命周期被有状态的类型给绑架了。无状态的类型的生命周期被有状态的类型给绑架了企业应用中，大多数的类型都是无状... 阅读全文

摘要：背景系统分析和设计的目的是找到一个合适的模型，以及如何应对模型的复杂性（大的关系网），好的模型更多的依赖：对问题的理解、看问题的角度、经验和模式等等，而如何应对复杂性呢？这更多的是技术性的问题，本文简单的聊聊，如何应对复杂性？我们做的只能是分解，如：架构层面横向分解（业务）子模块子模块聚合纵向分解（技术）流程层面迭代工作层面分工今天我想稍微重点说一下的是：更细粒度的组织命名空间。更细粒度的组织命名空间我们在大的层面一般都做了很好的分解（领导或架构师比较在意），而在实现层面，由于进度、历史等原因，我们的某些命名空间下有超过 50 个文件，我自己也造成过这样的结构，也深受其苦，这里不谈如何更细粒度 阅读全文

摘要：背景里氏替换原则是：子类可以替换其父类，这里的替换是指：在语义层面和业务层面可以替换，而非技术层面可以替换（始终可以替换）。示例类图分析这里就违背了里斯替换原则，“工厂”依赖的是“编号生成器”，但是“编号生成器”的两个实现却不能随意的替换器父类。 阅读全文

摘要：背景我们执着于面《向对象编程》，而多数情况我们都在使用《面向类型编程》，今天简单快速的回顾一下对象的之间的关系。先谈谈类型之间的关系类型之间的依赖，这里进一步划分为两类：显式依赖：在参数中显式的表达了依赖。隐式依赖：没有在参数中显式的表达依赖，直接在方法中创建了某个类型的实例，然后使用。类型之间的关联从某种程度上来讲也属于一种依赖，在这个维度讲，也可以将其划分为两类：显式依赖：使用构造方法或方法注入关联。隐式依赖：没有使用构造方法或方法注入关联，直接在构造方法中创建了某个类型的实例，然后赋值给关联。集合关联属于整体和个体的关系，复合关联属于整体和部分的关系，两者的区别在于语义上，技术上表现非常 阅读全文

摘要：背景第一次听说 SPI 是阅读《软件框架设计的艺术》，以后陆续在 Log4Net 和Quartz.Net中发现了以这种形式组织代码的方式，本位给出为什么要区分 SPI 和 API 的一个思考过程。从面向接口编程说起我们在“调用方”和“实现方”之间引入了“接口”，上图没有给出“接口”应该位于哪个“包”中，从纯粹的可能性上考虑，我们有三种选择：“接口”位于“调用方”所在的“包”中。“接口”位于“实现方”所在的“包”中。“接口”位于独立的“包”中。下面让我们依次分析这三种可能性，如果现实中确实有这种可能性，不如我们就为其起个名字以方便交流。“接口”位于“调用方”所在的“包”中我们先想象一个场景，以仓 阅读全文

摘要：备注不要重复自己，也不要重复别人，一旦养成了“拷贝和粘贴”的习惯，写程序的时候非常容易导致重复，好在一直暗示自己要稍后进行重构，本文给出一个重构的示例。需求需求：按照年、月和日显示销售数据，根据不同的周期类型，有三个问题需要注意：默认的日期范围不同图表中显示的格式不同默认的模拟数据不同（发布环境会使用真实的数据）如下图：第一遍代码（重复的代码）最爱的拷贝和粘贴。默认的日期范围不同 1 private void ResetStartDateAndEndDate() 2 { 3 this.EndDate = DateTime.Now; 4 ... 阅读全文

摘要：背景什么样的情况下需要引入父类？这就是今天的话题，也是对昨天的文章（设计原则：不要为了复用而使用继承）的一个补充。让我们站在抽象的角度思考这个问题，下面两幅图片是我们讨论的上下文。设计1设计2为什么引入了两个父类（Base2和Base3）？为了复用实现面对这个问题，我可能给出的一种回答是：A和B为了复用方法（行为）或数据（状态），如果我接受这个答案，那么如何应对“B和C之间的复用”，很多语言都是单实现继承的，这说明复用实现不是继承的本质原因，我对这个答案不够满意，继续思考。为了引入抽象如果我给出的答案是：为了引入抽象，这个答案本身就够抽象了，估计会被很多人批评（期望被批评），先让我简单的解释一 阅读全文

摘要：背景今天上午和以为朋友聊了一个设计问题：如何消除仓库相关的单据的Repository中的重复逻辑？如：入库单Repository和出库单Repository之间的重复。可以有很多方式消除重复，在不同级别消除重复，如：继承、组合、掺入、帮助类、帮助方法。本文只说出我的观点：不要为了复用而使用继承。为什么要得出这个结论：在单实现继承模型下，你复用了一个基类的实现，就不能复用其它基类的实现了，接口继承 + 扩展类型（Mixin）可以很好的解决这个问题。设计的演化下面我会演示：待重构的重复代码-》用继承消除重复-》用扩展类（Mixin）消除重复-》Ruby的鸭子类型 + Mixin的实现（元编程可以更 阅读全文

摘要：背景接触了一些非常优秀的编程人才，发现他们有一个共同的特点：“重视命名”，记得一位大师也曾说过：“命名和缓存是他最头痛的两个问题”，我不是一个注重细节的人，最起码从骨子里不是，因此我吃了不少苦头，我需要注重细节，从命名开始。这篇文章不会介绍如何更好的命名，关于这方面的资料，可以去买一些这些方面的书，设计模式固然必不可少，但是现在如果让我排一个优先级的话，我更关注代码可读性和命名，一些推荐的图书：《实现模式》、《代码质量》、《代码阅读》、《编写可读代码的艺术》、《微软框架设计规范》等。为何命名如此重要好的名称代表了合理的职责分配。好的名称代表了清晰的思路。好的名称代表了你对自己和他人的尊重。命名 阅读全文

摘要：背景知识控制反转反转传统的控制逻辑，常见的传统控制逻辑有：一、客户类型负责创建依赖。反转后的结构是：由IOC负责创建。二、客户类型调用框架。反转后的结果是：框架调用客户类型。依赖注入客户类型需要显式的声明其依赖，不要在客户类型中管理依赖的创建。IOC中文可以翻译为：控制反转容器或依赖注入容器。参考资料Inversion of Control Containers and the Dependency Injection patternInversionOfControl设计原则：我是如何使用“依赖注入”的.NET：在ASPX、ASHX和MVC中使用IOC容器（菜鸟必看）DDD：管理“工作单元实 阅读全文

摘要：名称解释多重继承：我没有使用多重继承的经验，因此这里不多说，大学学的C++，可惜没有学好。Mixin：一个Mixin是一个方法和属性的集合，不同的语言提供的实现机制不一样。类型定义的时候可以声明他想包含的Mixin（可以是多个），这些Mixin包含的方法会成为类型的一部分。使用动机代码复用 AND 运行时不改变。Mixin是推论，MixinTarget是定理。如：C#的IEnumerable（MixinTarget）只包含一个方法，根据这个方法（定理）Enumerable（Mixin）扩展了N个方法（推论）。示例（ExtJs4.2） 1 /// <reference path=" 阅读全文

摘要：依赖注入的定义控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题。 控制反转还有一个名字叫做依赖注入（Dependency Injection）。简称DI。构造方法注入代码示例1 public class Service2 {3 private readonly IDependService _dependService;4 5 public Service(IDependService dependService)6 {7 _dependService = dependServ... 阅读全文

摘要：有意识重复（懒惰的重复）问题：A处的代码和B处的代码很相似，但是又不完全相同。原因：开发人员的懒惰或技能不足，进行的是拷贝式的开发。方案：引入模板方法模式或回调机制（函数指针、委托和接口）。模板方法模式 1 public abstract class TemplateClass 2 { 3 public void Do() 4 { 5 DoCommonStep1(); 6 DoCustomStep2(); 7 DoCommonStep3(); 8 } 9 10 private void DoCommonStep1(... 阅读全文

摘要：接口的种类（API和SPI）从接口的被调用方式和被实现方式看，接口有API和SPI之分，见下图：API和SPI在物理组织方式上的建议（可根据情况选择其一）位于独立的Assembly中。位于调用方的Assembly中。API和SPI的演化方式：API可以增加功能，最好保持稳定。SPI可以减少功能，最好保持稳定。API和SPI的交互方式见下图：如何实例化接口（避免不了的问题）简单工厂（三种工厂模式都引入了新的抽象，因此最终还是要用简单工厂创建抽象的。适用于根据上下文实例化不同实例的场景）。服务定位器（适用于实例化边界对象或根对象的场景）。依赖注入容器（适用于多数场景，推荐用这种方式）。从面向接口编 阅读全文

摘要：有利于关注对象之间的关系和职责。有利于面向接口编程。有利于系统的维护和升级。 阅读全文

摘要：更加内聚（单一职责）。更加可读和清晰（自顶向下的编程，主流程很清晰，层次感很好）。更容易调试（更容易定位错误）。更容易重构和优化。更容易单元测试。更容易应用模式。更容易维护。 阅读全文

摘要：英文名字Favor composition over inheritance.说明继承的优点继承是多态的基础（在静态语言中），也是继承的主要目的。继承能带来一定的重用，但重用不是继承的主要目的。继承的缺点编译时绑定。强耦合。组合的优点运行时绑定。弱耦合。复用。组合的缺点不支持多态。备注组合和继承可以一起使用，并不冲突，组合模式、代理模式、装饰者模式就是这种思想的经典应用。 阅读全文

摘要：英文名字Program to a interface说明“面向接口编程”提供了一种好的“设计方式”，对于“设计方式”我都会问一声“为什么？”。隔离关注点（Dependency Inversion Principle）。隔离变化点（Open/Close Principle）。处理循环引用（程序集组织需要）。测试驱动开发的需要（设计方法需要）。协作式开发的需要（项目管理需要）。面向方面编程的需要（技术限制需要）。 阅读全文