自由理想的足迹

线-小箭头，中间的线区分：->关联 ：类中使用了对方的指针，或者引用--->依赖 ：函数参数中使用了对方，指针方式或者引用方式，可以相互依赖。菱形-线-小箭头，开始端的菱形区分：实心菱形-组合：菱形方拥有实线方的对象成员，这个成员单独存在没有意义，需要负责这个对象的生命期。空心菱形-聚合: 菱形方拥有实线方的对象成员，这个成员单独存在也是有意义的，或者是个单例，不负责对

State模式，类中不同的属性变化就是State变化，看对象运行时是否经常根据状态改变行为，或者类内部有多处根据枚举状态改变对象行为的逻辑，这时状态可以抽象成一个独立的状态类。    State模式将所有与一个特定的状态转换和状态对应的行为都放入一个状态子对象中，Context和State之间是双向关联的，因为Context管理了各个State子类，状态和相应逻辑虽然在State中，但是Sta

Observer模式，是一对多的关系或者多对多的关系，一般一对多是Subject类关联一个Observer基类的列表，当Subject数据改变时候，可以用Notify回调通知所有Observer子类的Update函数实现更新。但是一个Observer子类也是可以维护一个指向Subject类的指针的，使用了多对多，当Observer子类的Subject类状态和Subject类状态不一样的时候，那

Command模式，是在命令发出者和接受者之间插入了一个命令，命令需要接受者初始化，命令类注册给命令发出者，命令发出者直接执行命令接口抽象的Excute方法就可以了，所以命令模式只是命令的转发解耦作用；而解释器模式是将一种动作声明为命令，然后解释命令的含义，尤其是可以多个动作可以一起发出的时候。Command UML:抽象命令类(Command): 声明执行操作的接口。调用接收者相

转载自：http://blog.csdn.net/hguisu/article/details/7658644一、改善代码的三部曲   《设计模式》-> 《重构》-> 《重构与模式》。也就是设计->重构->重构出新设计。   《设计模式》主要详细说明20几种模式，为我们带来了常见设计问题的经典解决方案，从而改变了整个面向对象开发的面貌。为设计而著。   《重

每个程序员都该知道的10大编程格言（Kevin Pang）：编程格言1：无风不起浪 (There is no smoke without fire）编程格言2：预防为主，治疗为辅(An ounce of prevention is worth a pound of cure：）编程格言3：不要把鸡蛋都放在一个篮子(Don't put all your egg

谁都喜欢优雅和高效的代码，那么如何写出来。一、设计代码的理论原则：1）减少模块依赖，模块划分(插件化微内核化架构）。2）减少对象依赖，面向接口编程：尽量减少依赖关系，使之便于维护；3）高性能，开放关闭：性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。4）迪米特法则，组合优于继承。5）单一原则：简单函数：整洁的代码只做好一件事。本身逻辑简

这次的模式回顾，做下简单的总结。一、明确了重要的设计原则面向接口多态组合的OOP：一定要正确使用设计原则和设计模式，要不断的重构设计，但是不能过度设计，需灵活运用。1.系统要高内聚低耦合(顶层扇出比较大，中间扇出小，底层模块则有大扇入)，数据和表现分离MVC模式，数据结构和算法分离。扇入：是指直接调用该模块的上级模块的个数。扇入大表示模块的复用程度高。扇出：是指该模块直接调用的

几年前，笔者参与过一个基于复杂的代码和来自客户源源不断变更功能需求的大项目。开发过程中，项目经理需要与客户不断沟通确认，因为根据项目早期的技术规划，新需求的部分功能无法实现或实现成本过高。这种情况将开发者置于压抑状态下。作为一名软件开发人员，笔者并不认为编写软件应该如建造摩天大厦一番，随着项目的进行客户有越来越少的自由改变其想法。随着建筑业的发展，丝丝变化导致成本逐渐增加。软件并非

深度理解依赖注入作者: EagleFish(邢瑜琨)  来源: 博客园  发布时间: 2009-03-13 11:01  阅读: 72138 次  推荐: 11   原文链接   [收藏]  摘要：提到依赖注入，大家都会想到老马那篇经典的文章。其实，本文就是相当于对那篇文章的解读。所以，如果您对原文已经有了非常深刻的理解，完全不需要再看此文；但是，如果您和笔者一样，以前曾经看过

架构能力要好，写出拓展性强的代码。一定要用好抽象细分逻辑，参数化，单一职责。好的分层，好的归纳细节抽象为一个模块，利用好封装 继承 多态 接口 单一职责 中介者通信。合理的扇入扇出数。通信中的参数，可以设计为参数类。通过发送消息的形式进行通信。对于频繁的逻辑状态操作封装，对发送的消息，需要有一个状态类型，状态值，状态值参数列表；状态值参数

尽量减少依赖特别是对外有多接口，多表现时候，尽量对外统一一个接口， 一定要这样设计。调用依赖，调用依赖点一定要准确，随便调用或者不严谨的调用很容易导致问题。

如果本模块有很多控制变量，而且需要统一初始化，那个可以在管理器方设置一个变量，由本模块来取管理器的控制变量，而不是把所有控制变量都放置到管理器中初始化。降低模块之间的耦合度，经常要双向思考。也要独立并行模块思考，降低耦合度，同时开工。

当设计索引结构时候，一个数据容器，一个索引结构，但是有时候需要引入多个空间结构的，比如需要两个索引结构才能实现方便高效的算法。这就是典型的空间换时间算法思想。例如：3D空间，需要四元数来表示，而不是3元素。lua 的map需要2个索引结构。local UnorderedDict = class("UnorderedDict")function UnorderedDict:cto

--模块与模块之间的设计，除了大范围的设计模式，更多不属于模式的多种方法调用都可以通信。        -- 如何设计低耦合的，高内聚的模块之间通信？原则：        -- 1.用管理器用接口，尽量关联接口(管理器），在其它模块中用管理器设置和调用，而不是关联具体的类（会导致太错综复杂）。        -- 2.高内聚控制变量，关于本模块相关的控制尽量写在自身模块中，其它模块调用

现代计算机技术和通信技术都是建立在数字信号上面，无论是在传输中，还是在电子装置的内部。映射接口规范：数字信号最主要是将如何采用，如何量化，和如何编码；其中最核心的思想就是映射，按照规定映射，将物理电磁波信号映射为离散的01数字，用了数学中的转换思想。所以一个大的软件架构体系，一个良好设计的体系结构，都要有提早设计好的接口映射规范(无论是面向对象的接口，还是面向过程的函数指针），当新

来自：http://geek.csdn.net/news/detail/100051Go语言从面世就受到了业界的普遍关注，曾有文章分析，Go是最有可能改变未来IT技术的十大语言之一。本文作者列举了Go语言的设计模式和成例合集，并且还进行了详细的分类。创建型模式抽象工厂模式：提供一个接口用于创建相关对象的家族；Builder模式：使用简单的对象来构建复杂的对象；工厂方法模

Iterator模式-双向关联/聚合，Aggregate类是容器类需要将特定的迭代器创建出来返回Iterator基类指针，Iterator基类接口定义了访问容器的方法，Iterator特定子类定义了针对不同的聚合容器的实现遍历操作返回容器元素，这样容器返回的Iterator就可以遍历自己元素。也就是遍历操作从容器分离出来了，因为每一种类型的容器需要提供不同的Iterator子类，所以这种方式也会大

Mediator模式-双向调用，迪米特法则的经典应用网状结构简化为星型结构，不仅仅是维护了各个相关类那么简单，主要是定义了各个子类之间通信的映射（map或者数组）规则，当一个逻辑类注册了Mediator子类后发送消息会跳转到相应的其它逻辑类调用，且Mediator接口(有子类)定义了映射和操作方法给逻辑类用，逻辑子类有基类接口(繁多子类），基类接口注册给Mediator且定义标准操作方法，他们是双

1.智能指针智能指针的使用，auto_ptr赋值时候(显式直接赋值，隐式函数参数传递，返回值传递）都会丢失所有权，原来的指针被释放了，容易发生误用原来智能指针和智能指针所有权丢失的问题。建议使用boost的scope_ptr就够了或者使用auto_ptr仅是保护作用，需要赋值的需要用boost的shared_ptr.2.引用计数引用计数技巧：希望多个引用使用同一份内存数据，增加引用计数

UML类图是描述类之间的关系，关系有重复度和形式之分。重复度：单重复度，只存在一对一的关系。多重复度，用列表、vector或其它的数据结构维护一对多，多对多的关系这里再说一下重复度，其实看完了上面的描述之后，我们应该清楚了各个关系间的关系以及具体对应到代码是怎么样的，所谓的重复度，也只不过是上面的扩展，例如A和B有着“1对多”的重复度，那在A中就有一个列表，保存着B对象的N个引用，

最常用的编程范式计算机科学中主流的：1.面向对象编程2.面向过程编程3.泛型编程工程业务框架中特有的：4. 事件驱动编程，一些VC,VB,Java框架中。5.并发编程，分布式编程。非常优秀但是很少用的编程思想：1.模板元编程（操作编译决策）模板元编程特性：早期（编译期）的类型检查：例如一个容器，如果人们想让它装A类对象，但后来又把兄弟B类

C++用模板来实现泛型编程，模板分为函数模板和类模板。基本概念：泛型编程范式GP：模板也叫参数类型多态化。在编译时期确定，相比面向对象的虚函数多态，能够有更高的效率。泛型编程是从一个抽象层面描述一种类型的算法，不管容器类型是什么，是一种不同于OOP的角度来抽象具体算法。C++0X目前对GP的支持的趋势来看，确实如此，auto/varadic templates这些特性的加入象征着C

0.首要意识：        重构是通往良好的设计模式之路，重构要不断进行，设计模式也需要灵活变化（但是一定要有好设计的追求）。目的是为了写出高内聚低耦合，符合软件具体情况的可靠、健壮、可读、可复用、可维护的优雅架构和模块。误用模式会有很大害处，不用模式也会有很大害处，结合情景正确灵活的使用23种设计模式或者自己构造更加合适的模式才是正确之路。（遇到太复杂混乱的模块和架构，一定要记得用设计模式

代理模式并不仅是简单的委托，隐藏，减少调用层次；而规范做法是有公共的代理接口基类的。之所以为面向接口编程就在这些设计中体现。Proxy模式UML:在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用 Proxy模式。下面是一些可以使用Proxy模式常见情况：1) 远程代理（Remote  Proxy）为一个位于不同的地址空间的对象提供一个本地的代理对象。这个不同的地址空间

Adapter适配器模式关键知识点总结：1. Adapter总是继承Target（对外稳定的接口），继承或关联Adaptee类，本来是Target的接口却是借助Adptee类或者Adptee的子类来实现。2. Adpter用类继承方式，利于实现改变Adptee类的行为，但是不利于在多个Adptee子类间切换适配器或用多个适配器；Adpter用关联的方式来实现恰好相反，不利于改变Adpt

Strategy策略模式如果系统中某个类的某一行为存在多种实现方式，而且这些实现方式可以互换时使用策略模式。如果系统中某个类的对象存在多种状态，不同状态下行为有差异，而且这些状态之间可以发生转换时使用状态模式。Bridge模式是抽象接口逻辑，实现基类子类逻辑实现，通过抽象接口组合关联实现基类，在两个模块子类间进行桥接搭配统一接口。而Strategy模式调用方式没有抽象接口的。

组合模式使用情景：为了给外部一个多个子类组合而成的对象时候，为了分离耦合和提供拓展性可以采用组合模式-得到树形结构，而不是拓展性不好的管理器模式。装饰模式使用情景：为了方便修改装饰已经存在的类，保存现有类的引用，提供更可拓展的方案，而不是继承现有的类；装饰模式在需要被装饰体（游戏角色）身上经常使用，如果不继承被装饰（角色）类，而是独立做一个Plugin只是保存被装饰（角色）类的引用也可以做到，

OGRE的实例框架为Bridge模式，且看分析（读者首先要了解什么是Bridge)模式：SkeletalAnimation 继承了SdkSample,SdkSample继承了Sample,Sample继承了Ogre::GeneralAllocatedObject，但Sample作为所有例子子类的抽象。SampleContext继承了各种事件监听类接口，关联管理了Sample接口逻辑，包

Builder并不是简单的组装对象，而是通过已个统一的对外接口类Director类，Director类关的Builder类接口指针，Builder类由子类实现，Builder子类还需要关联Product类组织产品，才得到最终的复杂对象。Builder模式UML类图：其实Compsite和Decorate模式和Builder模式目的有些是一致的，为了获得复杂组合构建的对象，但是Builder

整理来自来自《大话设计模式》系统模块组件间目标：高内聚低耦合设计模式的目标就是高内聚低耦合，可读，可复用，易于应对业务变化可拓展。高内聚低耦合也是软件设计的目标。对内设计合理：数据和算法分离，逻辑和表现分离的MVC模式,对外:有统一简单的接口，也是软件工程里面的设计模块的目标。 接口：里氏原则-依赖倒转原则面向接口编程，父类接口实现调用框架，子类实现细节，细

FlyWeight模式就是对对象进行缓存，提高性能，是提高程序性能的经典方法之一。存储IO读取的资源，存储计算的结果，内存管理池，线程管理池等都广泛使用。FylWeight只要一个FlyWeightFactory对象管理类就可以了，对客户提供查询获取对象资源或计算结果，管理FlyWeight的基类和子类的创建和存储。FlyWeight UML:Facade模式，也叫外观模式

Template模式，关键的是在Template模板，是经典的面向对象核心思想体现，通过继承来实现代码的复用。Template基类实现大多数的函数，但是开放的函数留给子类来实现，体现了开放-关闭原则。除了多态继承复用，Template更加耀眼的方面是模板，通过Template基类模板定义一些调用框架逻辑,用户子类只需要根据自己的业务逻辑简单设置就可以了，这是很多程序开发框架使用的方式例如MFC

一、要记得重构重要性和基本的设计原则高内聚低耦合MVC架构插件化微内核化架构，依赖倒置接口原则/接口隔离原则，开放关闭原则/里氏原则，迪米特法则/组合优先，单一职责原则。代码需要不断重构 架构分离MVC，接口提取，类的抽象，分解组合，函数提取去掉重复冗余，通信尽量集中简单。重复冗余，结构混乱，通信混乱需要消耗巨大资源和陷入泥潭漩涡需要时刻警惕和规范化和不断重构。函数简单只做一件事情，健壮可

Visitor模式也是相互关联的，涉及到三个部分    第一个部分是数据元素部分必须是一个稳定的结构，抽象出来的接口Accept方法是给ObjectStruct使用的，关联了访问者模式的抽象方法，不同的数据元素会调用访问者接口不同的方法(一般访问者是为数据元素定制的，也就是访问者进来访问，有多少个元素会产生多少个分派处理）。    第二部分访问者接口中的方法数量是对应数据元素的统一了接口，

初衷，回顾改进之前游戏中设计的优劣，设计出简单健壮稳定，可读可维护，可拓展，可测试的优雅程序。基于弱联网模式，战斗逻辑全部在客户端，关键信息在服务器上同步跑，使用帧同步，基于投票的反外挂设计。架构设计思路整理：1.客户端划分层次管理，管理器依赖接口，CObjMgr客户端做表现和表现相关的动态运算, SObjMgr存放关键数据如基础属性道具加成。拆分复杂的数据泥团。 2.基于接口