第8章 SRP:单一职责原则 一个类应该只有一个发生变化的原因. 8.1 定义职责 在SRP中我们把职责定义为变化的原因.如果你想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.同时,我们很难注意到这一点.我们习惯于以组的形式去考虑职责.违反SRP的示例代码: public interface Modem { public void Dial(string pno); public void Hangup(); public void Send(char c); public ch

最近在读BOB大叔的敏捷软件开发,特别是TDD那一章节,启示真的不少,从测试驱动开发,讲到驱动表明程序设计的意图,从设计意图讲到对象依赖的解耦,从解耦建立Mock对象. 其实是对每个模块都编写单元测试,因为很多时候公司的项目赶的紧,所以为每个单元模块都编写测试是一件非常困难的事情,但是这本书,从测试驱动设计意图的角度讲如何来设计程序确实是一个非常好的思路 今天我读了OCP那一张,因为那一章节是C++写的,所以我用Java写了一遍,方便阅读同一章节的同学学习观摩,借鉴的都是书中的思想,所以献丑 p

Review of Agile Software Development: Principles, Patterns, and Practices 本书主要包含4部分内容,这些内容对于今天的软件工程师都非常的重要,它们是: ●Agile方法:主要讲述了如何去使用Agile方法,其中有很大一部分内容是告诉你为什么要这样做. ●面向对象设计原则:本书包含了11个面向对象设计原则,涵盖了包的设计和类的设计. ●设计模式:本书中讲述了23个设计模式,并都有具体的实例.讲解的重点在如何在实际的应用中去使用

最近在实践微服务化过程中,对其“单一职责”原则深有体会.那么只有微服务化才可以单一职责,才可以解耦吗?答案是否定的. 单一职责原则是这样定义的:单一的功能,并且完全封装起来. 我们做后端Java开发的,应该最熟悉的就是标准的3层架构了,尤其是使用Spring.io体系的:Controller.Service.Dao/Repository.为什么要分层?就是为了保证单一职责,数据模型的事情交给Controller,业务逻辑的事情交给Service,和数据打交道的事情就交给Dao/Repositor

理论性知识 定义 单一职责原则, Single responsibility principle (SRP): 一个类,接口,方法只负责一项职责: 不要存在多余一个导致类变更的原因: 优点 降低类的复杂度 提高类的可读性 提高系统的可维护性 降低变更引起的风险 特别说明 在我们的实际开发中,很多类或者方法都不完全符合单一职责原则.其实设计原则就是一种指导思想, 并不是要求开发人员必须遵守.根据实际业务需求,在能满足的情况下,尽可能去满足设计原则,这样才更有利于项目的后期维护和优化. 代码实战 非

摘要 本文介绍了传统软件开发(着重介绍了传统软件开发中常用的瀑布模型)和敏捷软件开发,以及敏捷开发和传统开发的对比. 一.传统软件开发 比较常用的几种传统软件开发方法:瀑布式开发.迭代式开发.螺旋开发作了对比分析. 瀑布式开发:1970年Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模式,瀑布模型将软件生命周期划分为制定计划.需求分析.软件设计.程序编写.软件测试和运行维护等六个基本活动,并且规定了它们自上而下.相互链接的固定次序

第8章 SRP:单一职责原则 一个类应该只有一个发生变化的原因. 8.1 定义职责 在SRP中我们把职责定义为变化的原因.如果你想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.同时,我们很难注意到这一点.我们习惯于以组的形式去考虑职责.违反SRP的示例代码: public interface Modem { public void Dial(string pno); public void Hangup(); public void Send(char c); public ch

1.0.0 Summary Tittle:[Scrum]-NO.40.EBook.1.Scrum.1.001-[敏捷软件开发:原则.模式与实践]- Scrum Style:DesignPattern Series:DesignPattern Since:2017-11-02 End:.... Total Hours:... Degree Of Diffculty:2 Degree Of Mastery:2 Practical Level:2 Desired Goal:2 Archieve Goa

第12章 ISP:接口隔离原则 不应该强迫客户程序依赖并未使用的方法. 这个原则用来处理“胖”接口所存在的缺点.如果类的接口不是内敛的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法都服务于一组不同的客户程序.这样,一些客户程序可以使用一组成员函数,而其他客户程序可以使用其他组的成员函数. ISP承认一些对象确实需要非内敛的接口,但是ISP建议客户不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内敛接口的抽象基类. 12.1 接口污染 如果子类

第14章 使用UML 在探索UML的细节之前,我们应该先讲讲何时以及为何使用它.UML的误用和滥用已经对软件项目造成了太多的危害. 14.1 为什么建模 建模就是为了弄清楚某些东西是否可行.当模型比要构建的真实实体便宜很多时,我们就会使用模型来研究设计. 14.1.1 为什么构建软件模型 当我们有一些确定的东西需要测试,并且使用UML要比使用代码测试的代价更低一些是,就使用UML.比如,我有一个关于某个设计的想法.我想知道团队中的其他开发人员是否认为它是一个好的想法,于是,我就在白板上画一幅UM

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape

第13章 写给C#程序员的UML概述 UML包含3类主要的图示.静态图(static diagram)描述了类.对象.数据结构以及它们之间的关系,藉此表现出了软件元素间那些不变的逻辑结构.动态图(dynamic diagram)展示了软件实体在运行过程中是如何变化的,其中描述了运行流程或者实体改变状态的方式.物理图(physical diagram)展示了软件实体不变的物理结构,其中描述了诸如源文件.库.二进制文件.数据文件等物理实体以及它们之间的关系. 查看如下代码,这段程序实现了一个基于简单

第11章 DIP:依赖倒置原则 DIP:依赖倒置原则: a.高层模块不应该依赖于低层模块.二者都应该依赖于抽象. b.抽象不应该依赖于细节.细节应该依赖于抽象. 11.1 层次化 下图展示了一个简单的层次化方案: 高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层.它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的.依赖关系是传递的. 下图展示了一个更为合适的模型: 每个较高层次都为它所需要的服

第9章 OCP:开放-封闭原则 软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改. 9.1 OCP概述 遵循开放-封闭原则设计出的模块具有两个主要特征: (1)对于扩展是开放的(open for extension).这意味着模块的行为是可以扩展的.当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为. (2)对于修改是封闭的(closed for modification).对模块进行扩展时,不必改动模块的源代码或者二进制代码.模块的二进制可执行版本,无论是可链接

敏捷软件开发_设计原则 单一职责原则(single responsibilities principle,SRP) 原理:一个类应该只有一个变化 分离职责:如果不耦合的职责那么很简单,如果两个职责耦合,将两个职责抽象为接口,通过继承两个接口将依赖关系抽离处理啊 开放封闭原则(open close principle,OCP) 软件实体(类,模块,函数等)应该是可以扩展的,但是不可修改 对扩展开放:当需求改变时,对模块可以扩展. 对修改封闭:对模块进行扩展时,不必改动模块的源代码或则二进制代码,

1.TEMPLATE METHOD 泛型,也就是这个模式,是可以基于泛型的. 我们往往会有一些算法,比如排序算法.它的算法部分,我可以把它放在一个基类里面,这样具体类型的比较可以放在子类里面. 看如下冒泡排序算法: package com.joyfulmath.agileexample.template.method; /** * @author deman.lu * @version on 2016-06-09 10:04 */ public abstract class BubbleSort

COMMAND 模式 command模式非常简单,简单到你无法想象的地方. public interface Command { void execute(); } 这就是一个command模式的样子.也许你会觉得,这有点多此一举吗.但是当你使用他的时候,command模式就会闪现光华. 这样一个场景:经理张三叫leader王二去开发一个项目, 王二就安排李四 去开发这个功能A. 李四何时执行,怎么执行就是他自己的事情了.  UML图如上所示: 代码如下: public interface Co

如果状态在运行过程中,不停的切换和改变,我们怎么办? 状态的迁移是我们生活和工程中非常普遍的一个概念.于是在数学上有一种理论来分析和解决这个问题. 有限状态机理论是一个非常成熟的理论,所有动作和流程的迁移可以归结为状态的迁移. 这个理论的前提是: 状态的数目是确定的,或者说是有限的. 状态的迁移方向是固定的,也就是有向的. 状态存储关于过去的信息,就是说:它反映从系统开始到现在时刻的输入变化.转移指示状态变更,并且用必须满足来确使转移发生的条件来描述它.动作是在给定时刻要进行的活动的描述.有多种

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,

单一职责原则 1.单一职责原则(SRP),就一个类而言,应该仅有一个引起它变化的原因 2.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当发生变化时,设计会遭受到意想不到的破坏 3.软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离 4.如果你能够想到多余一个的动静去改变一个类,那么这个类就具有多于一个的职责 开放-封闭原则(OCP)开-闭原则 开放-封闭原则的定义 开放-封闭原则:是说软件实体(