架构,设计模式的一些整理和杂思

1、前言

前些日,同事发了一些对于架构、设计、模式等自己的看法和总结。这也重新勾起我对这个问题的思考,什么是架构?什么是框架?设计模式与架构又有什么关系?与框架呢?什么是具体?什么优势抽象?这些架构、设计等的作用又是什么?工作两年中又有哪些地方用到了呢?于是重新翻看以前笔记,归纳整理给一个自己可以理解的能说服自己的解释整理下备忘,给自己后续学习提供指导。

2、模式的整理图(理论学习)

整理如下图:

点击放大查看大图

4、疑惑自我解释

  • 模式的理解

    正对当前环境下,不同的问题或者目标、动机的一组解决方案。【三者是一个过程、一个事物不可分割】不能离开具体环境谈问题和方案、也不能离开目标动机本身谈方案。

  • 什么是架构

    架构是蓝图,软件设计中的最高处抽象,正对的领域是软件的组成部分+联系+约束条件。不关心具体实现。具体中结合实际业务和软件质量标准设计出来的抽象的思路(如建筑中的设计图、规划图、蓝天)

  • 什么是框架

    框架在设计模式中的描述是一组协同工作的类、从这理解为框架是一个具体的一组的组合,其某种意义上上架构的实现和落地(如:MVC 是一种分层架构思想、SpringMCV,Struct2 、Android UI 都是MVC的具体实现),同一个架构思想有多重不同的实现。

  • 设计模式与框架、架构又有什么关系与框架呢?

    设计模式是正对具体的软件编码中(抽象、封装变化)具体问题的一些、特定环境的解决方案。与架构的联系不大。(架构只关注组件联系,抽象思想),而对框架而言,在框架的实现中会遇到各种的实际问题来解决。而这些问题的解决方案可由设计模式提供。【如MVC实现就是一种复合的设计模式组合】所有重某种意义上说,设计模式是框架实现的基石。

5、一些原则的备忘

5.1设计原则:

  • 封装变化

    软件中唯一不变的就是变化(业务需求增长改变、数据规模等待影响因素),我们要做的就是将变化封装起来。【将变化的依赖接口、依赖抽象】

  • 多用组合,少用继承

    组合形成的系统更具有弹性,不仅可以将算法族封装成类,更可以在运动时动态改变行为。

  • 针对接口编程,而不是不针对实现编程【降低耦合、隔离变化】

    针对接口编程的真正意思是针对超类类型 (supertype )编程

  • 为交互对象之间的松耦合设计而努力
  • 类应该对扩展开放,对修改关闭【解释:类的功能单一、函数无副作用修改也就相应的会关闭】
  • 依赖抽象,不依赖具体

    依赖倒置原则:只能高层组件(所谓高层组件就是由它的底层组件定义其行为的类)依赖低层组件。

  • 只和朋友交谈
  • 别找我,我会找你【IOC 是不是呢?】
  • 类应该只有一个改变的理由

5.2 架构模式

目前流行的架构模式分为:分层架构、基于事件的架构、微服务架构、微内核架构等。

点击学习参考:软件架构模式

5.4 设计模式

设计模式主要分为三大类:创建型、结构型、行为型(细分见上面大图)

推荐学习:head first 设计模式

基本备忘:

  • 迭代模式:

    提供一个方法,顺序访问一个聚合对象中的各个元素,而且又不暴露内部的表示

  • 组合模式:

    容许你将对象的组合成树的形式结构,来表现“整体/部分”层次结构。组合能让客户以一致的方式来处理个别对象,和对象组合。

  • 策略模式:

    定义一个算法族,分别封装起来,让他们之间可以相互替换,此模式让算法的替换独立于使用算法的客户。

  • 观察者模式:

    定义了对象之间的一对多的依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知,并自动更新。

  • 装饰者模式:

    动态的将责任附加到对象是。若要扩展功能,装饰者提供比继承更有弹性的替代方案。

  • 工厂模式:

    工厂方法模式:定义一个创建对象的接口,由子类决定要实例化的类是哪一个,工厂方法让类的实例化推迟到子类。

  • 抽象工厂模式:提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体的类。
  • 命令模式:

    “请求”封装成对象,以便使用不同的请求、队列、日志、和日志来参数化其他对象。命令模式也支持可撤销的操作。

  • 单列模式:

    确保一个类只有一个实例,并提供一个全局的访问点

  • 状态模式:

    容许一个对象在内部状态改变时候改变他的行为,对象看起来好像修改了它的类。

  • 适配器模式:

    将一个类的接口,转换成客户期望的另一个类的接口。适配器让然本不兼容的类可以相互合作。

    • 对象适配器:使用组合实现。
    • 类适配器:使用继承实现。
  • 外观模式:

    提供一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。

  • 模板方法模式:

    在一个方法中定义算法的骨架,而将一些步骤延迟到子类中,模板方法使得子类在不改变算法结构的情况下,重新定义算法的某些步骤(重新定义步骤,使用钩子实现)

关于代码模式

代码模式跟具体的语言相关,但是这些代码模式解决的问题一样(如:用不同语言实现能支持并发的单利模式用到的代码模式都是双检索模式)但是具体实现不一样。

推荐学习:结合自己的工作语言参考代码大全2相关代码最佳实践

时间: 2024-08-30 08:39:57

架构,设计模式的一些整理和杂思的相关文章

设计模式概述【整理】

设计模式不是很快的提高你的编码能力,设计模式的学习,旨在避免重复编码,减少劳动量.学习设计模式,对提高编写高效代码,大有裨益.学习设计模式,首先引入设计原则. 设计原则 设计模式的核心原则是:"开-闭"原则(  Open - Closed Principle 缩写:OCP  ),一切的一切都是围绕着"开-闭"原则展开的.. 意思是,在一个系统中,对于扩展是开放的,对于修改是关闭的,一个好的系统是在不修改源代码的情况下,可以扩展你的功能..而实现开闭原则的关键就是抽象

跨平台UI框架杂思——02

距离本系列最后一篇随笔<跨平台UI框架杂思--01>的发表已经过去了一年多.这一年多我都没怎么在外头写blog了(写东西都放在公司的 confluence page 里).这一年多我的"跨平台UI框架"实现了,并且用到了公司的产品中.我很欣慰地发现这一年多来,我都是按照最后一篇随笔的思路来开展的-- 硬件加速渲染 高可扩展性 灵活可替换的渲染框架 在Windows上面做透了 首先实现了 Direct2D 的渲染 由于这个框架是我在公司写的,所以目前暂且没能对外开源. 框架的

iOS开发中的错误整理,百思项目&#39;我的&#39;模块,tableFooterViewHeight的问题.提醒自己对KVO和Block的运用欠缺

一.错误分析:由于tableFooterView中的数据是通过请求服务器后得到的,tableFooterViewHeight也是根据请求过来的数据经过布局子控件而计算出来的.(注意:计算高度是在子线程中执行的),导致了给TableView设置了tableFooterView,tableFooterView的高度为0.如下图: 二.解决方案一:通过KVO监听自定义tableFooterView的高度变化 解决方案二:通过block,当自定义tableFooterView计算出高度后,才将自定义控件

朱晔的互联网架构实践心得S1E7:三十种架构设计模式(上)

朱晔的互联网架构实践心得S1E7:三十种架构设计模式(上) [下载本文PDF进行阅读] 设计模式是前人通过大量的实践总结出来的一些经验总结和最佳实践.在经过多年的软件开发实践之后,回过头来去看23种设计模式你会发现很多平时写代码的套路和OO的套路和设计模式里总结的类似,这也说明了你悟到的东西和别人悟到的一样,经过大量实践总能趋向性得出一些最佳实践的结论.架构设计也是一样,这里结合自己的理解分析一下微软给出的云架构的一些模式.话说微软干这方面的事情真的很厉害,之前翻译过的<微软应用架构指南>写的

微服务架构设计模式

目录 什么是微服务模式 单体结构的历程 单体地狱的银弹-微服务架构 扩展立方体和服务 微服务架构的好处和弊端 优点 大型的复杂应用程序可以持续交付和持续部署 每个服务都相对较小并容易维护 更好的容错性 更容易实验和采纳新的技术 弊端 服务的拆分和定义是一项挑战 分布式系统带来的各种复杂性 开发者需要思考到底应该在应用的什么阶段使用微服务架构 服务的拆分策略 识别系统操作 创建抽象领域模型 定义系统操作 根据业务能力进行服务拆分 从业务能力到服务 根据子域进行服务拆分 上帝类的处理 什么是微服务模

js架构设计模式——你对MVC、MVP、MVVM 三种组合模式分别有什么样的理解?

你对MVC.MVP.MVVM 三种组合模式分别有什么样的理解? MVC(Model-View-Controller)MVP(Model-View-Presenter)MVVM(Model-View-ViewModel)请大家谈一谈各自的理解吧,对比之下更能明确特征和适用的范围,菜鸟们畅所欲言,老鸟大牛们请多多指点! 2 条评论 按投票排序 按时间排序 10 个回答 王韦恩卑鄙,我编程序,我约. 知乎用户.里德.jogen 等人赞同 只是一点浅见啊 折叠也活该... M-V- X 本质都是一样的

《JavaScript设计模式 张》整理

最近在研读另外一本关于设计模式的书<JavaScript设计模式>,这本书中描述了更多的设计模式. 一.创建型设计模式 包括简单工厂.工厂方法.抽象工厂.建造者.原型和单例模式. 1)简单工厂 又叫静态工厂方法,由一个工厂对象决定创建某一种产品对象类的实例. 两种实现方式,第一种是通过类实例化对象创建,第二种是创建一个新对象然后包装增强其属性和功能. demo代码. 2)工厂方法 通过对产品类的抽象使其创建业务主要负责用于创建多类产品的实例. 将工厂方法看作是一个实例化对象的工厂类. demo

js架构设计模式——理解javascript中的MVVM开发模式

理解javascript中的MVVM开发模式 http://blog.csdn.net/slalx/article/details/7856769 MVVM的全称是Model View ViewModel,这种架构模式最初是由微软的MartinFowler作为微软软件的展现层设计模式的规范提出,它是MVC模式的衍生物,MVVM模式的关注点在能够支持事件驱动的UI开发平台,例如HTML5,[2][3] WindowsPresentation Foundation (WPF), Silverligh

Java的23种设计模式详解整理之创建型模式

最近重新阅读"四巨头"的设计模式. 对一些设计模式有了更多的理解. 原著中的例子是C++写的,不好理解. 这里我换成了Java, 代码示例仅供参考,没有具体实现. 介于个人水平有限,如有纰漏,请指正.有问题的朋友可以私信我或者发我邮箱(请到我主页查看),我看到就会回复. 希望和大家一起进步. 工作中有时候最困难的不是怎么去实现一个功能,而是怎么去设计一个功能.我常常会因为频繁改动需求大费脑筋.之后我在思考如何将一个功能在设计之初就做好扩展的准备,防止需求变动导致大面积的修改.code之