我有一壶酒，足以慰风尘

「设计模式(六) - Builder模式」一、可定制化的电脑的组装在生活中并不陌生，大家都有电脑，当然需求不一样配置也不一样。以Macbook Pro为例，像UI设计对图像模块GPU要求比较高，跑IDEA的对内存要求就比较高，可能会加装32G内存更高的就是64G了。如果是对付日常的办公，刷剧那默认的配置就已经足够了，如8G标配。类似的在软件开发过程中，需要根据需要自定义搭配不同的选择来构建对象的一般能够用Builder模式很好的解释，看看具体的定义是怎样的。二、Builder模式维基百科The

「设计模式(五) - 代理模式」一、处处可见的“代理”“代理”在平常生活司空见惯，点外卖，租房子找中介，买飞机票等等。基本上用手机就能完成，也就是不直接接触到对象而通过中介的方式达成自己的需求，它和装饰器在实现上是有点相似的，容易混淆。就目前的项目当中其实没用到代理模式，但还是有必要了解这种结构型模式。二、代理模式 Proxy通俗的讲，出于某种原因不能够直接访问目标对象，如目标对象是受保护的内容、远程内容、权限问题等等。需借助代理对象作为调用者与目标对象的中介来操作目标对象的一种结构型设计模式Pr

「设计模式(四) - 责任链模式」一、能力越大责任越大顾名思义，“责任链”就像是一根链条串联起来的一系列操作，每个操作都息息相关。请假的审批流程，报销流程等等依据不同职位对应的人员完成相应的审批操作；可以说是层层推进的。而我们最终关心的结果就是同意或者驳回。二、责任链模式 Chain of Responsibility当请求端Client发出请求时，为了降低请求者Client与处理对象们Handlers之间的耦合；同时满足众多Handlers都能有机会参与到对请求的处理，将Handler对象组成一

「设计模式(三) - 状态模式与StateMachine」一、抱怨不能解决问题，但思考可以作为开发，最头痛的无非就是需求的变动了，毕竟产品的思维太过于“超前”；频繁的变动有时候真的让人捶胸顿足。明明想好的设计可能重新修改。但是面对同样的问题为什么有的同学就能游刃有余呢？承认别人优秀很难，但不得不服的是，别的同学在设计之初确实考虑的很多，包括各种可能性，系统被设计的很健壮，拥有优异的扩展性。提醒自己面对棘手的问题时，多思考思考总能找到解决的办法，也算是一种成长的方式吧。二、状态模式 State Patt

「设计模式(二) - 观察者模式」一、回复TD退订日常生活中，这种短信无处不在，各种广告，在互联网高速发展的今天，个人信息可以说是透明的。没有任何隐私可言，类似这种通知其实跟我们开发过程使用的观察者模式(Observer Pattern)如出一辙。更贴切的像初中时代，英语学习的周报订阅，一个班级大部分还是会订阅，基本上一周一期。这个算是比较典型的观察者模式也即-发布-订阅。可以这样理解，Publishers+Subscribers=Obeserver Pattern。像这种一对多的关系，一个对象状态的改

「设计模式(一) - 策略模式」一、从if-else说起代码中if-else的出现频率不必多说，几乎的逻辑实现都离不这个组合。但是带来了方便的同时，也带来了多重嵌套代码块。套用重构的一句话，这些都是代码的坏味道。过多的条件判断必然增加了系统不稳定性，同时也给扩展带来了不便因素。当然优化的方式多种多样，策略模式Strategy仅仅只是其中简单的一种。二、策略模式 Strategy行为模式的一种，定义了一系列平行的算法，将实现与责任相分离并加以封装，当然各个策略之间是可以相互转化的。由客户端决定使用何

「UML建模语言」UML类图在实际开发的地位不言而喻，当我们拿到一个需求，首先应该做的是给出技术方案。根据技术方案来实现具体的功能细节不但可以保证对大体的流程做到心中有数，即使出现临时的改动也仅仅改技术方案的具体实现也是不容易出现错误。实际开发中很多同学包括自己都是想到哪儿写到哪儿，这样的做法不友好也不推荐。统一建模语言(UML)中的类图是一种静态的结构图，用于构建和可视化面向对象的系统的图形表示法。主要描述的内容有：类、属性、操作(方法)、对象之间的关联关系。「主要关系表示」1.继承关

「设计原则之二」一、单一职责原则单一功能职责，一个类应该有且仅有一个引起它变化的原因，也即一个类只负责一项职责。不仅仅是类，实际开发过程中，方法的的处理也是遵循尽可能处理单一的功能，否则应该考虑将它们进行拆分。如果在设计时不遵循单一职责原则，一个类或者方法承载了多个功能，那么某一个职责变化时，有可能影响其他职责的变化，导致系统的不可控。破坏单一职责原则，系统可读性、可维护性都会降低；造成大量代码冗余。1.作用降低了类或方法的复杂度。(由于粒度小，派生的类难免会增加，但同保持系统的稳定比

「设计原则 之一」一、开闭原则顾名思义，在软件设计中应当遵循对扩展开放，而对修改关闭。也即在实际开发过程中，当需求变动业务调整时，在不改动源码的情况下可以扩展以支撑新的功能；这也要求了在设计之初制定技术方案时应有前瞻性。遵循开闭原则的好处：提高代码的复用性、可维护性、有利于单元测试。实现：在面向对象的设计中，通常可以通过定义接口或者抽象类来约束相同属性或者一般通用的实现(抽象)，这样具体派生实现类可以将具体的实现封装在内部。即使业务变化，我们只需要相应的派生出一个实现类就可以实现扩展。不过在实