wyxhd2008的专栏

定    义：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定他们的具体类优    点：            1、封装性，每个产品的实现类不是高层模块要关心的，他们关心的是接口，抽象            2、产品族内的约束为非公开状态，具体的产品族内约束在工厂内实现缺    点：抽象工厂模式的最大缺点就是产品族扩展非常困难，但是产品等级非常容易扩充使用场景：一个对象

定      义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行，门面模式提供一个高层次的接口，使得子系统更易于使用优      点：              1、减少系统的相互依赖              2、提高了灵活性              3、提高了安全性缺      点：最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，应用场景：  

设计模式是为了解决类在交互过程中的繁琐问题，为后期的扩展方面做好充足的准备，而生活中也无处不存在繁琐的问题，人与人的沟通，人与事的沟通，事与事的沟通，提升一个层次，那都是类与类之间的沟通，设计模式也同样能够解决日常生活中的问题，所以想研究下日常生活与设计模式结合起来将会是什么情况？

主要是为了巩固已经学习到的设计模式知识，并改进已经开发了的系统。

一、我的理解        单例模式，其目的是让某个类只有一个实例，并且方便于外界访问，从而实现方便的对实例个数的限制       很明显，采用单例模式有如下作用:       1、方便对不能并发的资源统一管理       2、节省内存开销，避免每一次处理都新建对象       3、能方便共享，让所有对象访问    二、应用       生活中有

一、我的理解             1、为一系列的产品创建提供支持             2、减轻创建对象所需要知道的细节            二、现实运用            1、女娲造人            2、导航网站，访问导航网站就能任意去想要去的网站，而无需知道具体网站地址三、代码using System;using Syste

一、个人理解      1、定义创建产品的接口，将实际创建工作延迟到子类中实现      2、实现调用者与具体产品的解耦      3、调用者通过工厂来生成产品二、生活运用         1、数据库访问控制，支持access,sql,mysql,oracle多种数据库         2、反射工厂模式，利用传入的参数即可找到指定需要的对象         3、

一、个人理解            1、解决复杂对象的创建            2、同样的构建过程有不同的表现            3、处理繁琐而且顺序不太重要的事情二、实际运用             1、手机组装             2、个人每天的生活，吃饭、睡觉、打扫卫生三、代码using System;using System.Coll

面向对象设计（OOD）核心原则让我的程序模块达到“高内聚低耦合”,这是来自于30年前兴起的结构化设计（structured Design），但是同样适用于我们的OOD。

我的理解是服务层是处于我的应用程序业务层和表现层之间的应用程序边界,边界可能是很薄的一层类设计或者是分布式服务网络跃点。它是一个与技术无关的名词。由表现层直接调用，契约，执行命令（修改状态（CUD））或者是查询返回dto（数据迁移对象）（cms，命令-查询分离）。他对业务逻辑层接口很清楚，组织业务逻辑 微服务形成宏服务，适配表现层。

定      义：定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新优      点：               1、观察者和被观察者之间是抽象耦合               2、建立一套出发机制应用案例：             先来看看类图：          1.抽象主题角色:把所有对观察者对象的引用

定      义：将对象组合成树形结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性优      点：               1、高层模块调用简单               2、节点自由增加使用场景：               1．你想表示对象的部分-整体层次结构               2．你希望用户忽略

定      义：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起共走的两个类能够在一起工作优      点：            1、适配器模式可以让连个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成            2、增加了类的透明性            3、提高了类的复用度            4、灵活非常好用

定    义：定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤优    点：             1、封装不可变部分、扩展可变部分             2、提取公共部分代码，便于维护             3、行为由父类控制，子类实现缺    点：按照正常的设计，抽象类负责申明最抽象，最一般的事务属性

定    义：为其他对象提供一种代理以控制对这个对象的访问优    点：            1、职责清晰，真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事务，附带的结果就是                编程简洁清晰             2、高扩展性，在主题角色发生了变化，代理类完全可以在不做任何修改情况下使用           

定    义：将一个复杂对象的构建于它的表示分离，使得同样的构建过程可以创建不同的表示优    点：             1、封装性             2、建造者独立，容易扩充             3、便于控制细节风险使用场景：             1、相同的方法，不同的执行顺序，产生不同的时间结果时，可以采用建造者模式             2、多

定    义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象，Prototype模式同工厂模式，同样对客户隐藏了对象的创建工作，但是，与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的，达到了“隔离类对象的使用者和具体类型（易变类）之间的耦合关系”的目的。优    点：            1、性能优良，特别是在循环内产生大量对象时，

定    义：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们             之间的交互。优    点：减少了类之间的相互依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中间者，减少了依赖，当然也减少了类见耦合缺    点：随着业务流程的复杂，中介者会膨胀很大，而且逻辑复杂动    机：在软件构建

定      义：使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合，将这些对象连成一条链，并沿着这条链传递该请求，             直到有对象处理它为止优      点：将请求和处理分开，请求者可以不知道是谁处理的，处理者不用知道请求的全貌，两者解耦，提高了灵活性，责任链模式减低了请求               的发送端和接收端之间的耦合，使多个对象有机会

定      义：定义一组算法，将每个算法都封装起来，并且使他们之间可以互换优      点：              1、算法可以自由切换              2、避免使用多重条件判断              3、扩展性好缺      点：              1、策略类数量多              2、所有的策略类都需要对外暴露使用场景：

定    义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢             复功能优    点：           1、类间解耦，调用者角色与接受者角色之间没有任何依赖关系，调用者实现功能时只需调用command抽象类的execute方法即可，                不用管是具体哪个接受者执行

 概      要：在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；               并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”               能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使

1：软件中唯一不变的就是变化。在软件开发过程中需求是不停的变化，随着客户对系统的认识，和现有开发功能和软件的认识，也许以开始他提出的需求就是背离的。记得网上有一句笑话，师说需求变化的：程序员XX遭遇车祸成植物人，医生说活下来的希望只有万分之一，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们根据XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了，你快来呀！”，奇迹终于发生了，XX醒来了，第一句话：“需求又改了在设计和架构中，凡事无绝对，作为架构师或者项目负责人你必须永远的清晰认识到没有