![](https://img-blog.csdnimg.cn/20201014180756913.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
OOAD
文章平均质量分 56
ices
专注架构设计、OOAD、设计模式、重构、Java EE!
展开
-
一些软件设计的原则
以前本站向大家介绍过一些软件开发的原则,比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识,正如我在《再谈“我是怎么招聘程序”》中所说的,一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则,我认为这些东西属于长期经验总结出来的知识。这些原则,每一个程序员都应该了解。但是请不要原创 2012-11-30 12:42:50 · 1447 阅读 · 0 评论 -
接口隔离原则(Interface Segregation Principle)
作用:它指导我们如何正确地进行接口设计!定义1) 一个类对另外一个类的依赖性应当是建立在最小的接口上Ø 一旦一个接口太大,则需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。Ø ISP可以达到不强迫客户(接口的使用方)依赖于他们不用的方法——在接口设计中应该保证,接口的实现类应该只呈现为单一职责的角色(遵守SRP原则);Ø原创 2012-11-18 00:29:08 · 1980 阅读 · 2 评论 -
组合/聚合复用原则(Composition/Aggregation Principle)
定义又叫合成复用原则。原则就是在一个新的对象里面通过关联关系(包括组合关系和聚合关系)使用一些已有的对象,使之成为新对象的一部分,新对象通过委派调用已有对象的方法达到复用其已有功能的目的。也就是,要尽量使用类的合成复用,尽量不要使用继承。组合/聚合复用原则要点:就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分,新的对象通过向这些对象的委派达到复用已有功能的目的。这个原则原创 2012-11-18 00:35:32 · 2158 阅读 · 0 评论 -
迪米特法则(Law of Demeter)
迪米特法则(Law of Demeter, LoD)又称为最少知识原则(Least Knowledge Principle, LKP),它有多种定义方法,其中几种典型定义如下:(1) 不要和“陌生人”说话。 (2) 只与你的直接朋友通信。 (3) 每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。 (4) 一个对象原创 2012-11-18 00:36:33 · 1326 阅读 · 0 评论 -
小例子背后的大道理——从DIP中“倒置”的含义说接口的正确使用
小例子背后的大道理——从DIP中“倒置”的含义说接口的正确使用提纲开灯的例子暗流涌动Guru眼中的依赖DIP(依赖倒置原则)为什么要解耦合?接口的坏味道同一张类图的不同解释——真假DIP了解DIP有什么用?DIP用在什么地方?下回预告参考文献开灯的例子 选开灯做例子,是因为这个例子既常见又简单,而且潜在的需转载 2012-11-18 09:54:30 · 1006 阅读 · 0 评论 -
小例子背后的大道理——Adapter模式详解
小例子背后的大道理——Adapter模式详解上回问题回顾 前文说到一位用户拿着业界标准开关(一个标准的StandardSwitcher,它依赖IStandardSwitchable接口才能工作,然而目前我们的灯并不支持这个接口)出现在我面前,叫嚣着他的“标准开关”应该能打开我们的灯。好吧,这个需求是合理的,的确应该支持。但是该死的是,为什么没有早一点儿知道这个标准的存在转载 2012-11-18 09:55:25 · 1202 阅读 · 1 评论 -
里氏代换原则(Liskov Substitution Principle)
作用它指导我们如何正确地进行继承与派生,并合理地重用代码!定义子类型必须能够替换掉它们的父类型、并出现在父类能够出现的任何地方。这个就是尽量用多态的方法编程,也就是GRASP模式中的多态。如果对于每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。换言之,一个软原创 2012-11-18 00:31:21 · 1763 阅读 · 0 评论 -
单一职责原则(Single Responsibility Principle)
1 作用它指导我们如何提高代码的可重用度!2 定义一个类应该仅有一个引起它的变化的原因(职责),或者说一个类只负责一个功能领域中的相应职责。这条原则也称为类设计的“高内聚性原则”。(l)含义之一:避免相同的职责(也称为功能)分散到不同的类中实现。(2)含义之二:也应该要避免一个类承担过多的职责。将过多的职责耦合在一个类中导致了脆弱设计。软件设计真正要做的许多内容,就是发原创 2012-11-18 00:22:41 · 3429 阅读 · 6 评论 -
详细设计的新视角--全员设计
详细设计的瓶颈详细设计的重要性,个人认为是毋庸置疑的。需求说明书从用户的角度描述了软件系统应有的模样(如功能、性能、用户界面与交互方式等方面的要求),而详细设计则把用户需求映射到计算机这个层面,即软件系统应该如何运作才能展现出用户期望的模样?撰写详细设计是一个逐步细化、深入的过程。设计撰写人必须与系统分析员反复讨论,以透彻理解用户需求;一项需求可能有多种方式实现,设计者必须与系统分析员转载 2012-11-19 23:08:04 · 942 阅读 · 1 评论 -
架构设计的基本原则
低耦合、高内聚、防止变异(使用接口和适配器防止变异)、关注分离。1 关注分离横向分层、纵向分区(1) 将有关事务模块化,封装到单独的构件(例如子系统)中,并且调用其服务;(2) 使用装饰者,将所关注的事物(例如安全)置入Decrator对象中,Decorator对象包裹内部类并提取其服务,装饰者在EJB技术中被称为容器,EJB容器围绕内部对象的业务逻辑,在外部的装饰者中增添原创 2012-11-23 22:52:37 · 4567 阅读 · 0 评论 -
如何做系统分层
数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。在PetShop的数据访问层中,并没有使用ORM,从而导致了代码量的增加,可以看作是整个设计实现中的一大败笔。业务逻辑层:是整个系统的核心,它与这个系原创 2012-11-25 09:44:27 · 14046 阅读 · 2 评论 -
设计不足与过度设计
什么是设计不足?设计出来的系统复用性差,扩展性不强,不能灵活的应对变化,简言之,设计没到位。设计不足,多半是因为经验有限,设计能力有限。什么是过度设计?设计出来的系统比恰到好处要复杂臃肿的多,过度的封装、一堆继承、接口和无用的方法,超复杂的xml配置文件,简言之,客户需求是要一把杀鸡的刀,你给设计了一把牛刀(杀鸡用牛刀)。过度设计,多半是因为有设计的癖好,喜欢炫耀或玩弄无谓的技巧,或是原创 2012-12-25 22:13:26 · 1597 阅读 · 0 评论 -
软件设计的思考与关注点
软件设计是一个十分复杂且没有规律可遵循的思维发散过程。设计软件系统是非常有挑战性的,因为一方面需要你聚焦在今天的需求,同时要求可以适应未来对功能的修改和增加。面对软件最大的敌人—需求的变化,我们更多的是通过堆积木的方式堆砌代码。随着系统的上线运营,客户需求不断的变化与扩充、程序BUG的不断涌现,我们天天在为了修正BUG而干十万火急的工作,下班了还提心吊胆实施地是否给自己提了除错单。原创 2012-12-25 23:20:20 · 1686 阅读 · 1 评论 -
如何开展软件设计
花了三年的时间研究如何做系统设计,在学习总结大师的设计观点后,自己对设计也有一定的理解。因此特意对设计的理解进行梳理,计划梳理的知识点如下:(1)对软件设计的思考(2)设计的困惑(3)设计的关注点(4)如何实现组件式设计? 1)划分职责 2)发布服务 3)建立协作 4)应对变化(5)敏捷设计过程(6原创 2012-12-28 01:37:10 · 1205 阅读 · 0 评论 -
我理解的设计模型
原创 2012-12-28 01:36:26 · 1025 阅读 · 0 评论 -
“开-闭”原则(Open-Closed Principle)
1.1 “开-闭”原则(Open-Closed Principle)1.1.1 作用它指导我们如何提高代码的可扩展性!1.1.2 定义(1)Open(Open for extension)模块的行为必须是开放的、支持扩展的,而不是僵化的。(2)Closed(Closed for modification)在对模块的功能进行扩展时,不应该影响或大规模地影响已有的程原创 2012-11-18 00:18:01 · 5133 阅读 · 0 评论 -
共性和可变性分析
考虑设计中什么应该是可变的。这种方法与关注引起重新设计的原因刚好相反。它不是考虑什么会迫使设计发生改变,而是考虑什么能够在不引起重新设计的前提下改变。这时主要关注的就是对变化的概念进行封装,这时许多设计模式的主题。如何在问题领域中找到不同变化,如何找到不同领域中的共同点。找到变化的地点,称为“共性分析”,找出如何变化,称为“变性分析”。共性分析就是寻找一些共同的要素,它们能够帮助我们理解系原创 2012-11-18 00:15:57 · 4501 阅读 · 0 评论 -
GRASP通用职责分配软件模式
1. 概述它的核心思想是“职责分配(Responsibility Assignment)”。GRASP提出了几个基本原则,用来解决面向对象设计的一些问题。Craig Larman在《Applying UML and Patterns》一书中提出了GRASP设计模式的概念。作者称其为设计模式,其实,更好的理解应该为设计原则。因为,与GoF等设计模式不同的是,GoF等设计模式是针对特定问题而原创 2012-11-18 00:00:12 · 6853 阅读 · 1 评论 -
优质代码的十诫
1.- DRY: Don’t repeat yourself.DRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。DRY原创 2012-11-30 12:55:02 · 817 阅读 · 0 评论 -
如何提高代码质量
1.1 如何提高代码质量我们抛开任何具体的技术,来谈谈如何提高代码质量。如何提高代码质量,相信不仅是在座所有人苦恼的事情,也是所有软件项目苦恼的事情。如何提高代码质量呢,我认为我们首先要理解什么是高质量的代码。高质量代码的三要素我们评价高质量代码有三要素:可读性、可维护性、可变更性。我们的代码要一个都不能少地达到了这三要素的要求才能算高质量的代码。1.1.1 可读性强一提到原创 2012-11-17 15:34:18 · 1003 阅读 · 0 评论 -
关注点分离
关注点分离Separation of Concerns 是计算机科学中最重要的努力目标之一。这个原则,就是在软件开发中,通过各种手段,将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题,就是相对较易解决的。问题太过于复杂,要解决问题需要关注的点太多,而程序员的能力是有限的,不能同时关注于问题的各个方面。正如程序员的记忆力相对于计算机知识来说那么有限一样,程序员解决问题的能力相对于原创 2012-11-17 15:39:04 · 2051 阅读 · 0 评论 -
面向对象的特征
特征传统看法新思维对象一堆数据和方法具有方法的数据拥有责任的实体,这些责任定义了对象的行为。(我们应该关注对象的意图行为,而不是对象如何实现。)对象的设计多关注应该做什么,而不是如何实现它。对象设计的基本观点:关注动机而不是实现。(关注对象要做什么,能帮助我们免于过早地操心实现细节,从而将这些实现细节隐藏起来。)原创 2012-11-17 13:49:30 · 1080 阅读 · 0 评论 -
面向对象设计原则
设计原则名称设计原则简介重要性单一职责原则(Single Responsibility Principle, SRP)类的职责要单一,不能将太多的职责放在一个类中。 ★★★★☆ 开闭原则(Open-Closed Principle, OCP) 软件实体对扩展是开放的,但对修改是关原创 2012-11-17 13:58:09 · 1178 阅读 · 0 评论 -
UML各种图形及作用
分类图的名字介绍结构型图 静态图类图(Class Diagram)类图用于定义系统中的类,包括描述类之间的联系(如:关联、依赖、聚合)以及类的内部结构,即类的属性和操作。因此类图是描述系统中类的静态结构,即它所描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图(Ob原创 2012-11-30 22:37:07 · 6388 阅读 · 0 评论 -
系统设计概述
1 系统设计的关键软件设计活动的关键又是什么呢?还是让我们回到现实世界去寻找答案吧!在远古时期,人类只能通过徒步从一个地方到达另一个地方。后来发现马可以被驯服,通过马车能更快地从一处到达另一处。再后来,人类逐步发明了自行车、汽车和飞机,且每一次发明都使得交通效率得以大幅提高。在这里,马车、自行车、汽车和飞机都共同地为了解决交通效率问题。很显然,马车、自行车、汽车和飞机都是不同的概念,人类原创 2012-11-17 13:55:09 · 3815 阅读 · 0 评论 -
面向对象设计--提升抽象层次
从最早的汇编语言中使用的子例程到结构化编程,然后到面向对象、面向组件以及面向服务。我觉得都是不断地提升抽象的层次。所以编程方法没有好坏,只有适合不适合。在汇编时代问题规模都很小,所以我们需要的抽象能力不需要太强。而现代的软件项目,问题的规模非常庞大,需要考虑的事情非常多(虽然纯粹的技术含量不一定有汇编时代的高),我们就必须使用抽象层次更高的方法来匹配我们的问题规模。面向对象编程方法的出现也不外原创 2012-11-17 15:30:56 · 1186 阅读 · 1 评论 -
导致代码重复的原因
1) 懒惰,所以能够容忍不好的代码2) 技能不足,常常会出现不必要的重复代码3) 缺乏沟通,团队之间协作不够,因而重复制造轮子重用的关键是保持合适的粒度,以及对关系的解耦。粒度表现在方法级,就是需要编写许多小的方法,找到类中可以重复调用的职责,抽取为单独的方法。类级的粒度可以采用辅助类,也可以通过寻找共性,以泛化的方式提取共性特征。对于模块级,则主要需考虑模块的原创 2012-11-17 15:35:39 · 1736 阅读 · 0 评论 -
包结构设计原则
1 共同封闭原则Common Closure Principle(CCP)一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包,便影响了包中所有的类。一个更简短的说法是:一起修改的类,应该组合在一起(同一个包里)。如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。CCP原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。原创 2012-11-17 13:52:11 · 1610 阅读 · 0 评论 -
依赖倒转原则(Dependency Inversion Principle)
作用:它指导我们如何正确地消解模块间的依赖关系,同时它也是框架设计的核心原则。 依赖倒置原则的本质就是要求将类之间的关系建立在抽象接口的基础上的。Robert Martin这样描述依赖倒置原则[Martin 1996]:传统的策略是把复杂的系统“化整为零,各个击破”。这就是通常所说的分解。SA方法(结构化的分析)也是采用这样的分解策略,把大型和复杂的软件系统分解成若干个人们易于理解和易原创 2012-11-18 00:33:43 · 2518 阅读 · 0 评论 -
小例子背后的大道理——用户需求+设计原则+正确应用 =设计方案
上回的最后,来了两个用户,分别提出了两个不同的需求。一个要求用两个开关控制一个灯,一个要求用一个开关控制所有的灯。本回将就这两个需求进行分析。我写这段话的时候并没有想出这个需求的具体方案,重要的过程,思路有时候比结果更重要。所以,我的方案可能会"跑偏";但是如果你能从过程中体会到些什么,那这篇就没有白写。 两个开关控制一个灯。这个问题好像很简单,把两个Switcher的Switch转载 2012-11-18 09:49:46 · 1036 阅读 · 0 评论 -
GRASP模式(转)
GRASP,全称为General Responsibility Assignment Software Pattern,即通用职责分配软件模式,它由《UML和模式应用》(Applying UML and Patterns)一书作者Craig Larman提出。与其将它们称之为设计模式,不如称之为设计原则,因为它是站在面向对象设计的角度,告诉我们怎样设计问题空间中的类与分配它们的行为职责,以及明转载 2012-11-18 00:04:33 · 784 阅读 · 0 评论 -
关注点分离
好的架构设计必须把变化点错落有致地封装到软件系统的不同部分。要做到这一点,必须进行关注点分离。Iuar Jacobson在《AOSD中文版》中写道:“好的架构必须使每个关注点相互分离,也就是说系统中的一个部分发生了变化,不会影响其他部分。即使需要改变,也能够清晰地识别出那些部分需要改变。如果需要扩展架构,影响将会最小化,已经可以工作的每个部分都将继续工作。上述论述中的三句话:“系统原创 2013-02-27 16:50:52 · 5028 阅读 · 0 评论