设计模式与系统架构学习笔记之设计模式部分

模式:

一个特定的环境,一个问题,一个解决方案

核心思想:进行设计的复用

环境+问题+解决方案

设计模式:描述了定制化的相互通行的对象与类,以及解决特定环境中的通用设计问题。

单例模式:

确保一个类仅有一个唯一的实例,并且提供一个全局的访问点。

解决方案:

将构造函数声明称私有类型,屏蔽通过直接实例化的形式来访问;

控制全局只有一个实例的类-Static;

提供一个可以获得实例的方法,用于返回类的实例,并且保证得到的是同一个对象;

(是否已经存在,存在的话,直接返回;不存在的话,创建新的实例,再对外返回)

开闭原则:

对扩展开放,对系统修改封闭

抽象化是开闭原则的关键。

单一职责原则:

高内聚性原则

避免相同的职责(也称为功能)分担到不同的类中实现;

避免一个类承担过多的职责;

减少类之间的耦合关系;

“发现职责”并“分离职责”;

工厂模式:分离对象的“创建”和对象的“使用”

模板方法模式:分离“共性功能实现”和“个性扩展”

命令模式:分离“命令的请求者”和“命令的实现者”

里氏替换原则:

主要针对继承的设计原则;

子类型必须能够替换掉他们的父类型,并出现在父类能够出现的任何地方;

子类可以扩展父类的功能,但不能改变父类原有的功能;

原则:

子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法;

子类可以增加自己特有的方法;

当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松;

当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格;

依赖倒置原则:

将依赖关系倒置为依赖接口

上层模块不应该依赖于下层模块,他们共同依赖于一个抽象;

父类不能依赖子类,他们都要依赖抽象类;

抽象不能依赖与具体,具体应该要依赖于抽象;

接口隔离原则:

一个类对另外一个类的依赖性应该是建立在最小的接口上;

客户端不应该依赖那些他不需要的接口;

如何避免不良好的接口设计:

用多个专门的接口,而不是用单一的总结口;

一个接口就只代表一个角色;

使用接口隔离原则拆分接口时,首先必须满足单一职责原则

合成复用原则:

又称为组合/聚合复用原则;

尽量使用对象组合,而不是继承来达到复用目的;

一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象;

新对象通过委派调用已有对象的方法达到复用其已有功能的目的。

要尽量使用组合/聚合管理,少用继承。

迪米特法则:

要求一个软件实体应该尽可能少的与其他实体发生相互作用

                      (未完待续……)

时间: 2024-10-11 02:52:08

设计模式与系统架构学习笔记之设计模式部分的相关文章

【《软件设计模式与体系结构》学习笔记】软件设计模式概论

[<软件设计模式与体系结构>学习笔记] 软件设计模式的概念 软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道.大量的软件设计模式都是之前从事软件设计开发的前人经过大量的实践而摸索出来的,用于帮助后来者快速高效且高质从事软件开发的. 软件设计模式的要素 软件设计模式一般会包含四个基本要素: 模式名称:此种设计模式的名字: 问题:是设计者所面临的设计场景,也就是此种设计模式所适用的情况: 解决方案:描述设计细节,通常会采取UML等图示的方式来进行设计模式

连载00:推荐:软件体系设计新方向:数学抽象、设计模式、系统架构与方案设计(简化版)(袁晓河著)

我正在推出本人的心得体会<软件体系设计新方向:数学抽象.设计模式.系统架构与方案设计(袁晓河著)>,由于我从未进行过相关的推广,所以经验欠缺,希望各位给出宝贵意见,谢谢!软件设计正在迈入一个瓶颈时代,软件设计正在越来越衰老!越来越无法推陈出新!设计模式.架构模式.重构.面向对象.AOP.等等一切,我无法忍受这样的陈词滥调,无法忍受这样的似是而非,是什么阻挡我们前进的步伐,是我们不够努力,是我们不思进取,好像都不是.对,都不是!其实这都是我们的思维定势,我们一直以来都是以一种模糊的方式来推进软件

linux系统构建学习笔记

嵌入式系统构架:(硬件+软件)应用软件层: Application GNU C Library(glibc)文件系统: 系统层: API(Systern Call Interface) OS Core + Power Mannager+ File Manager + GUI Mannager TCP/IP HTTP WAP DataBase Browser DDI(Device Drver Interface) 板级支持:BSP:Board Support Package       OEM A

转:大型网站架构学习笔记

前言 最近一直在拜读两本书: 1.李智慧老师的<大型网站技术架构 核心原理与案例分析> http://www.linuxidc.com/Linux/2015-11/125137.htm 2.曾宪杰老师的<大型网站系统与Java中间件实践> http://www.linuxidc.com/Linux/2015-11/125138.htm 看了并结合自己目前的工作进行了思考,感觉获益匪浅.受益良多,自己对大型网站的理解又有了不少的加深,下面分享一下自己的学习笔记. 学习笔记 1.大型网

大型网站架构学习笔记

前言 最近一直在拜读两本书: 1.李智慧老师的<大型网站技术架构 核心原理与案例分析> 2.曾宪杰老师的<大型网站系统与Java中间件实践> 看了并结合自己目前的项目进行了思考,感觉获益匪浅.受益良多,自己对大型网站的理解又有了不少的加深,下面分享一下自己的学习笔记. 学习笔记 1.大型网站架构的发展史(红字就是每一步发展历程的关键) (1)从一个小网站发展起来,一台服务器,应用程序.数据库.文件等所有资源都在一台服务器上 (2)网站业务的发展,一台服务器逐渐不能满足需求,因此要将

列式存储 HBase 系统架构学习

   一.Hbase简介 HBase是一个开源的非关系型分布式数据库(NoSQL),它参考了谷歌的BigTable建模,实现的编程语言为 Java.它是Apache软件基金会的Hadoop项目的一部分,运行于HDFS文件系统之上,为 Hadoop 提供类似于BigTable 规模的服务.因此,它可以容错地存储海量稀疏的数据. HBase在列上实现了BigTable论文提到的压缩算法.内存操作和布隆过滤器.HBase的表能够作为MapReduce任务的输入和输出,可以通过Java API来存取数据

列式存储hbase系统架构学习

一.Hbase简介 HBase是一个开源的非关系型分布式数据库(NoSQL),它参考了谷歌的BigTable建模,实现的编程语言为 Java.它是Apache软件基金会的Hadoop项目的一部分,运行于HDFS文件系统之上,为 Hadoop 提供类似于BigTable 规模的服务.因此,它可以容错地存储海量稀疏的数据.HBase在列上实现了BigTable论文提到的压缩算法.内存操作和布隆过滤器.HBase的表能够作为MapReduce任务的输入和输出,可以通过Java API来存取数据,也可以

连载39:软件体系设计新方向:数学抽象、设计模式、系统架构与方案设计(简化版)(袁晓河著)

1. 简单性 由于对简单的理解会很多,具有最少构成要素的结构,符合简单性观念.在众多可能中选择一个最方便的方式,也符合简单性观念.根据奥康的剃刀原则"如无必要,勿增实体"即简单有效的原则.然而简单性是一个相对的概念,是在不同的时空.不同的视角下存在的一种可被成本最低的理解. 但是在系统构架中,具有简单的设计方案,往往具有最少的约束,从而带来最为直接的处理方式,由于简单,所以设计开发都显得容易掌控,其稳定性和可靠性会大大的增强,同时由于简单,所以一旦存在需要扩展,其扩展的约束也是非常少,

解析大型.NET ERP系统架构设计 Framework+ Application 设计模式

我对大型系统的理解,从数量上面来讲,源代码超过百万行以上,系统有超过300个以上的功能,从质量上来讲系统应该具备良好的可扩展性和可维护性,系统中的功能紧密关联.除去业务上的复杂性,如何设计这样的一个协作良好的系统,搭建开发人员基础平台,一直是我研究的方向. SouceCounter(版本3.3.91.79)对源代码的统计信息如下: 下面来详细解析一下这个系统的设计架构,纯.NET技术架构方案,C/S WinForms系统. 系统分为Framework和Application两个部分,前者是框架(