标签：
前些日，同事发了一些对于架构、设计、模式等自己的看法和总结。这也重新勾起我对这个问题的思考，什么是架构？什么是框架？设计模式与架构又有什么关系？与框架呢？什么是具体？什么优势抽象？这些架构、设计等的作用又是什么？工作两年中又有哪些地方用到了呢？于是重新翻看以前笔记，归纳整理给一个自己可以理解的能说服自己的解释整理下备忘，给自己后续学习提供指导。
整理如下图：
模式的理解
正对当前环境下，不同的问题或者目标、动机的一组解决方案。【三者是一个过程、一个事物不可分割】不能离开具体环境谈问题和方案、也不能离开目标动机本身谈方案。
什么是架构
架构是蓝图，软件设计中的最高处抽象，正对的领域是软件的组成部分+联系+约束条件。不关心具体实现。具体中结合实际业务和软件质量标准设计出来的抽象的思路（如建筑中的设计图、规划图、蓝天）
什么是框架
框架在设计模式中的描述是一组协同工作的类、从这理解为框架是一个具体的一组的组合，其某种意义上上架构的实现和落地（如：MVC 是一种分层架构思想、SpringMCV,Struct2 、Android UI 都是MVC的具体实现），同一个架构思想有多重不同的实现。
设计模式与框架、架构又有什么关系与框架呢？
设计模式是正对具体的软件编码中（抽象、封装变化）具体问题的一些、特定环境的解决方案。与架构的联系不大。（架构只关注组件联系，抽象思想），而对框架而言，在框架的实现中会遇到各种的实际问题来解决。而这些问题的解决方案可由设计模式提供。【如MVC实现就是一种复合的设计模式组合】所有重某种意义上说，设计模式是框架实现的基石。
封装变化
软件中唯一不变的就是变化（业务需求增长改变、数据规模等待影响因素），我们要做的就是将变化封装起来。【将变化的依赖接口、依赖抽象】
多用组合，少用继承
组合形成的系统更具有弹性，不仅可以将算法族封装成类，更可以在运动时动态改变行为。
针对接口编程，而不是不针对实现编程【降低耦合、隔离变化】
针对接口编程的真正意思是针对超类类型 （supertype ）编程
为交互对象之间的松耦合设计而努力
类应该对扩展开放，对修改关闭【解释：类的功能单一、函数无副作用修改也就相应的会关闭】
依赖抽象，不依赖具体
依赖倒置原则：只能高层组件（所谓高层组件就是由它的底层组件定义其行为的类）依赖低层组件。
只和朋友交谈
别找我，我会找你【IOC 是不是呢？】
类应该只有一个改变的理由
目前流行的架构模式分为：分层架构、基于事件的架构、微服务架构、微内核架构等。
点击学习参考：软件架构模式
设计模式主要分为三大类：创建型、结构型、行为型（细分见上面大图）
基本备忘：
迭代模式：
提供一个方法，顺序访问一个聚合对象中的各个元素，而且又不暴露内部的表示
组合模式：
容许你将对象的组合成树的形式结构，来表现“整体/部分”层次结构。组合能让客户以一致的方式来处理个别对象，和对象组合。
策略模式：
定义一个算法族，分别封装起来，让他们之间可以相互替换，此模式让算法的替换独立于使用算法的客户。
观察者模式：
定义了对象之间的一对多的依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知，并自动更新。
装饰者模式：
动态的将责任附加到对象是。若要扩展功能，装饰者提供比继承更有弹性的替代方案。
工厂模式：
工厂方法模式：定义一个创建对象的接口，由子类决定要实例化的类是哪一个，工厂方法让类的实例化推迟到子类。
抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体的类。
命令模式：
“请求”封装成对象，以便使用不同的请求、队列、日志、和日志来参数化其他对象。命令模式也支持可撤销的操作。
单列模式:
确保一个类只有一个实例，并提供一个全局的访问点
状态模式：
容许一个对象在内部状态改变时候改变他的行为，对象看起来好像修改了它的类。
适配器模式：
将一个类的接口，转换成客户期望的另一个类的接口。适配器让然本不兼容的类可以相互合作。
外观模式：
提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
模板方法模式：
在一个方法中定义算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类在不改变算法结构的情况下，重新定义算法的某些步骤（重新定义步骤，使用钩子实现）
代码模式跟具体的语言相关，但是这些代码模式解决的问题一样（如：用不同语言实现能支持并发的单利模式用到的代码模式都是双检索模式）但是具体实现不一样。
标签：
原文地址：http://blog.csdn.net/start0609/article/details/51337632
