Facade 模式
Facade（外观）模式为子系统中的各类（或结构与方法）提供一个简明一致的界面，隐藏子系统的复杂性，使子系统更加容易使用。他是为子系统中的一组接口所提供的一个一致的界面。这在某种意义上与Adapter及Proxy有类似之处，但是，Proxy（代理）注重在为Client-Subject提供一个访问的中间层，如CORBA可为应用程序提供透明访问支持，使应用程序无需去考虑平台及网络造成的差异及其它诸多技术细节；Adapter（适配器）注重对接口的转换与调整；而Facade所面对的往往是多个类或其它程序单元，通过重新组合各类及程序单元，对外提供统一的接口/界面。
在遇到以下情况使用Facade模式
- 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
- 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
- 当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，你可以让它们仅通过Facade进行通讯，从而简化了它们之间的依赖关系。
Facade模式的优点
- 它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。
- 它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。Facade模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要.在大型软件系统中降低编译依赖性至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用Facade可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。Facade模式同样也有利于简化系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。
远程外观模式
远程外观模式为细粒度对象提供粗粒度的外观来改进网络上的效率。任何对象可能作为远程对象使用时，经常需要一个粗粒度的接口来减少完成某些任务所需要的调用次数。一个粗粒度的远程外观建立在大量的细粒度之上。所有细粒度对象都没有远程接口，并且远程外观不包括领域逻辑。远程外观所要完成的就是把粗粒度的方法转换到低层的细粒度对象上。
远程外观有有状态和无状态之分。无状态的远程外观可以组成池，这样就可以提高资源的使用率和和效率。
除了提供一个粗粒度的接口以外，远程外观还增加了其他几个功能。例如，它的方法中可以提供安全检查。远程外观同样也提供事务控制。远程外观中的方法可以开始一个事务，当做完需要工作后提交事务。每次调用都是一次完整的事务，应为当结果返回客户的时候，你不会希望这次事务还在运行中，因为这种长时间的运行将会使事务变得效率很低。
Gateway模式说明
事实上Gateway是一个非常简单的包装类（wrapper）模式。封转外部资源，创建一个简单的API，并用这个Gateway将对该API的调用转移到外部资源上。
Gateway模式的使用场景
如果必须通过一个复杂的接口与可能的位于系统之外的事物交互，你应当考虑入口模式。使用入口将复杂性封装起来，而不要让复杂性蔓延到整个系统中。使用Gateway几乎没有什么弊端，同时又可以使系统中Gateway之外的代码可读性显著提高。使用Gateway一个显而易见的优点是是你资源来替换另一种资源变得更容易。但是即使你认为资源不会发生任何变化，你仍可以使用入口模式所带来的简单性和可测性中获益。如你有数个子系统，将他们解耦的另一种选择是映射器，但是，映射器远比入口复杂。我们使用入口来完成大部分资源访问。
Gateway模式和其他模式的区别
- 外观模式对较复杂的API进行简化，通常由服务的作者提供，而且是通用的。gateway则是客户方为了其特定应用而撰写的。此外，一个外观通常暗示一个与原始接口不同的接口，但在入口中可以只是简单地照搬被包装的接口，这种Gateway用于将来替换资源或测试目的。
- 适配器模式修改一个已经实现的接口，使其与另一个你所用到的接口相匹配。Gateway模式中通常没有一个已经存在的接口，虽然你可能会使用一个适配器来讲一个实现映射到一个Gateway的接口上。此时适配器是入口类实现的一部分。
- Media模式通常用将多个对象解耦，使得他们无需相互引用，而只要与Media发生关联。Gateway模式中通常只涉及两个对象，而且被包装的资源并不知道入口的存在。
封装的定义
在程序上，隐藏对象的属性和实现细节，仅对外公开接口,控制在程序中属性的读和修改的访问级别；将抽象得到的数据和行为（或功能）相结合，形成一个有机的整体，也就是将数据与操作数据的源代码进行有机的结合，形成“类”，其中数据和函数都是类的成员。
封装的目的是增强安全性和简化编程，使用者不必了解具体的实现细节，而只是要通过 外部接口，一特定的访问权限来使用类的成员。
封装的大致原则
- 把尽可能多的东西藏起来.对外提供简捷的接口.
- 把所有的属性藏起来
参考资料
什么是抽象
什么是抽象。以下这段内容载录自百度百科。
抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。例如苹果、香蕉、生梨、葡萄、桃子等，它们共同的特性就是水果。得出水果概念的过程，就是一个抽象的过程。要抽象，就必须进行比较，没有比较就无法找到在本质上共同的部分。
抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。例如苹果、香蕉、生梨、葡萄、桃子等，它们共同的特性就是水果。得出水果概念的过程，就是一个抽象的过程。要抽象，就必须进行比较，没有比较就无法找到在本质上共同的部分。
共同特征是指那些能把一类事物与他类事物区分开来的特征，这些具有区分作用的特征又称本质特征。因此抽取事物的共同特征就是抽取事物的本质特征，舍弃非本质的特征。所以抽象的过程也是一个裁剪的过程，将不同的、非本质性的特征全部裁剪掉了
所谓的共同特征，是相对的，是指从某一个刻面看是共同的。比如，对于汽车和大米，从买卖的角度看都是商品，都有价格，这是他们的共同的特征，而从其他方面来比较是，他们则是不同的。所以在抽象时，同与不同，决定于从什么角度上来抽象。抽象的角度取决于分析问题的目的。
抽象化主要是为了使复杂度降低，以得到论域中较简单的概念，好让人们能够控制其过程或以综观的角度来了解许多特定的事态。
关键是抽象
“关键是抽象”这个章节载录自《敏捷软件开发原则、模式与实践》的第九章 开放-封闭原则的9.3小节——关键是抽象。
象(Abstraction)是简化复杂的现实问题的途径，它可以为具体问题找到最恰当的类定义，并且可以在最恰当的继承级别解释问题。它可以忽略一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题，而只是选择其中的一部分，暂时不用部分细节。抽象包括两个方面，一是过程抽象，二是数据抽象。
在c++、Java或是其他任何的OOPL中，可以创建出固定却能够描述一组任意个可能行为的抽象体。这个抽象体就是抽象基类。而这组任意个可能行为的则表现为可能的派生类。
模块可以操作一个抽象体。由于模块依赖于一个固定的抽象体，所以它对于更改是可以关闭的。同时通过这个抽象体派生，也可以扩展此模块的行为。
参考文档
这两周都在阅读和体会了Bob大叔的面向对象设计原则方面的一些文章。这些文章除了对这些面向对象的设计原则做了详细的释义以外，另外还有不少的观点可以让我们在架构、设计的过程中使用。其中的五个面向对象的设计原则，他们是：
每个原则有专门的PDF文档可以阅读。
主要的文章入口时http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
另外还有一个PPT是也是介绍这些原则的。http://butunclebob.com/files/SDWest2006/AdvancedPrinciplesOfClassDesign.ppt
关于面向对象的这些内容几乎每年都会重读一遍，而每次都有新的收获，也正印证了“温故而知新”这句老话。
这是《软件开发沉思录》这本书阅读笔记的第二篇，第一篇是软件开发沉思录阅读笔记一是对第六章——对象健身操的阅读笔迹。
第七章——迭代经理是什么角色
什么是迭代经理？
ThoughtWorks的高级架构师Fred George把迭代经理描述成“面向内部的管理角色。迭代经理负责保证故事在团队中流动的顺畅，这牵涉到合理分配任务、在技能需要改变的时候建议更换团队成员。”
怎样成为好的迭代经理？
每天，迭代经理都必须倾听团队的需要并且作出回应。其主要职责就是培养一台润滑良好的“机器”，并依据要求的质量在项目范微内交付功能。
迭代经理应该在技术熟练度和业务知识之间达到一个平衡。敏捷领袖应该“同时对客户和技术都由深刻的理解，这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开团队与客户，以及与管理阶层之间的关系。
同时，迭代经理必须推动、主张和保障团队成员的权利。
迭代经理不做什么？
与项目经理不同，迭代经理需要在工作第一线，与团队成员一起面对每日的工作活动。
迭代经理与项目
作为次要目标，我期望看到因为迭代经理的工作，团队成员在项目结束的时候变得更为优秀。团队内充满信任，持续提高技能——这是迭代经理的工作。
迭代经理要争取把团队拧成一根绳，让所有的成员能同舟共济。
第十章——领域标注
在过去十年里，众多软件开发者意识到：软件应用程序中最大的复杂度来自于软件要处理的实际问题领域。正因为如此，所谓“领域驱动设计”有两个前提：
- 大部分软件项目关注的焦点是业务领域和领域逻辑；
- 复杂的领域设计应该基于模型来进行。
换句话说，领域驱动设计将用业务领域术语表述的业务领域的面向对象模型置于软件系统的核心。数据通常保存在关系数据库里，但看待数据的主视角是领域对象，而不是数据库表和存储过程。核心业务逻辑集中保存在领域模型中，而不是散步在用户界面和应用程序的服务层里。
如果遵循领域驱动设计方法，得到的软件系统就会清晰地区分出领域模型和基础设施（及界面）：前者通常较为稳定、生命周期较长；后者通常生命周期较短，并且与具体的技术（例如O/R映射或者WEB框架）相关。这里的挑战在于如何保持两者之间的分野，从而使两者能够各自保持可复用性：一方面，领域模型应该能够在不同的应用程序、不同的服务中使用，或是在技术升级以后继续使用；另一方面，基础设施应该能用于支撑各种领域模型。当然最终的目标是实现基础设施的行业标准化（无论是采用商用软件还是开源软件），从而使应用程序开发者能专注于问题领域。
敏捷
敏捷估计和规划的12条指导原则
- 让整个小组参与。
- 在不同层次上进行规划。
- 使用不同度量单位，让对规模和持续时间的估计保持独立。
- 用功能或者日期来体现不确定性。
- 经常重规划。
- 跟踪进度并沟通
- 承认学习的重要性。
- 规划具有适当规模的功能。
- 确定功能优先级。
- 把估计和计划建立在事实上
- 保留一些松弛度。
- 通过前瞻规划协调做个小组。
Bob大叔关于Scrum和敏捷的7条缺陷
- 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
- 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
- Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
- 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
- Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
- 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
- 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。
Agile Methodology Mashups
- Pair Programming
- Daily Scrum/Standing Meeting
- Kanban/Burn Down Charts
- Test First Development
敏捷开发中高质量 Java 代码开发实践
OOD & OOP
Composition versus Inheritance
-
Programming to an Interface, Not an Implementation
-
Creational Patterns Considered Obsolete
-
Inversion of Control Containers
-
Composition Realized
[Inheritance] can cause problems when you’re trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability.
Object composition is defined dynamically at run-time (at startup, config-time in most IoC containers –Chad) through objects acquiring references to other objects. Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a payoff. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies (!!! Very important –Chad)
Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class (configured and managed by the IoC container –Chad).
其他
Tags,无序,分类和家族相似
看似普通的Tag其实有着丰富的哲学含义
