设计模式是6大原则还是7大原则
设计模式应该是六大原则吧1、开闭原则(Open Close Principle)开闭原则就是说对扩展开放,对修改关闭。
在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。
所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。
想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。
2、里氏代换原则(Liskov Substitution Principle)里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。
LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。
—— From Baidu 百科3、依赖倒转原则(Dependence Inversion Principle)这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。
4、接口隔离原则(Interface Segregation Principle)这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。
还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。
所以上文中多次出现:降低依赖,降低耦合。
5、迪米特法则(最少知道原则)(Demeter Principle)为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
6、合成复用原则(Composite Reuse Principle)原则是尽量使用合成/聚合的方式,而不是使用继承。
...
体系结构,软件构架和设计模式之间的区别和联系
结构:程序功能实现的逻辑 框架是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一方面也可以说框架是可被应用开发者定制的应用骨架。
框架亦可称为应用架构,在特定领域基于体系结构的可重用的设计。
也可以认为框架是体系结构在特定领域下的应用。
框架的例子如MVC。
设计模式 在一定的环境中解决某一问题的方案 构件通常是代码重用,而设计模式是设计重用,框架则介于两者之间,部分代码重用,部分设计重用,有时分析也可重用. 构架是architecture:它是对软件系统的系统组织,是对构成系统的 构件的接口,行为模式,协作关系等体系问题的决策总和。
它不仅涉及 到结构与行为,而且还涉及到系统的使用,功能,性能,适应性,重 用性,可理解性 设计模式比框架更为抽象 设计模式在碰到具体问题后,才能产生代码;框架已经可以用代码表示 设计模式是比框架更小的体系结构元素: 框架中可以包括多个设计模式简单点说:结构 < 设计模式 < 架构 <框架 结构+算法=程序(功能代码块) 程序与程序之间进行调整=设计模式 多个设计模式相组合(组件)=架构(系统)...
软件架构设计和企业架构模式之间的关系是什么?
一般而言,架构有两个要素:它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(Task-flow)。
所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。
显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点,一是建筑风格,二是建筑模式。
独特的建筑风格和恰当选择的建筑模式,可以使一个独一无二。
正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:·可靠性(Reliable)。
软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。
·安全行(Secure)。
软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
·可扩展性(Scalable)。
软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。
只有这样,才能适应用户的市场扩展得可能性。
·可定制化(Customizable)。
同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性(Extensible)。
在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展
需要说明一个软件系统的各个层次的每一个程序(模块)设计考虑的文...
摘要: 本文是在概要设计实践和学习中的一些心得与学习笔记,希望与大家分享,如有不妥之处欢迎指正。
关键字: 概要设计,结构化,OOD 正文: 在需求明确、准备开始编码之前,要做概要设计,而详细设计可能大部分公司没有做,有做的也大部分是和编码同步进行,或者在编码之后。
因此,对大部分的公司来说,概要设计文档是唯一的设计文档,对后面的开发、测试、实施、维护工作起到关键性的影响。
一、问题的提出 概要设计写什么?概要设计怎么做? 如何判断设计的模块是完整的? 为什么说设计阶段过于重视业务流程是个误区? 以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确? 结构化好还是面向对象好? 以上问题的答案请在文章中找。
二、概要设计的目的 将软件系统需求转换为未来系统的设计; 逐步开发强壮的系统构架; 使设计适合于实施环境,为提高性能而进行设计; 结构应该被分解为模块和库。
三、概要设计的任务 制定规范:代码体系、接口规约、命名规则。
这是项目小组今后共同作战的基础,有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法,大家就有了共同的工作语言、共同的工作平台,使整个软件开发工作可以协调有序地进行。
总体结构设计: 功能(加工)->模块:每个功能用那些模块实现,保证每个功能都有相应的模块来实现; 模块层次结构:某个角度的软件框架视图; 模块间的调用关系:模块间的接口的总体描述; 模块间的接口:传递的信息及其结构; 处理方式设计:满足功能和性能的算法 用户界面设计; 数据结构设计: 详细的数据结构:表、索引、文件; 算法相关逻辑数据结构及其操作; 上述操作的程序模块说明(在前台?在后台?用视图?用过程?······) 接口控制表的数据结构和使用规则 其他性能设计。
四、概要设计写什么 结构化软件设计说明书结构(因篇幅有限和过时嫌疑,在此不作过多解释) 任务:目标、环境、需求、局限; 总体设计:处理流程、总体结构与模块、功能与模块的关系; 接口设计:总体说明外部用户、软、硬件接口;内部模块间接口(注:接口≈系统界面) 数据结构:逻辑结构、物理结构,与程序结构的关系; 模块设计:每个模块“做什么”、简要说明“怎么做”(输入、输出、处理逻辑、与其它模块的接口,与其它系统或硬件的接口),处在什么逻辑位置、物理位置; 运行设计:运行模块组合、控制、时间; 出错设计:出错信息、处错处理; 其他设计:保密、维护; OO软件设计说明书结构 1 概述 系统简述、软件设计目标、参考资料、修订版本记录 这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时,对于非功能性的需求例如性能、可用性等,亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何,务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分,将解释设计是怎么来实现这些的。
2 术语表 对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。
3 用例 此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。
4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose) 4.2 系统结构设计 这部分要求提供高层系统结构(顶层系统结构、各子系统结构)的描述,使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离,对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述,此处不用再重复,可以指引读者参考需求说明。
如果系统提供了对其它系统的接口,比如说从其它软件系统导入/导出数据,必须在此说明。
4.4 约束和假定 描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助,那么系统可能还受到其它的约束。
这种情况下,要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。
实现的语言和平台也会对系统有约束,同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。
5 对象模型 提供整个系统的对象模型,如果模型过大,按照可行的标准把它划分成小块,例如可以把客户端和服务器端的对象模型分开成两个图表述。
在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数。
聚合和继承关系必须清楚地确定下来。
每个图...
交互设计原则有哪些
面向对象设计原则-开放封闭原则,对于扩展是开放的,对于修改是封闭的。
修改(增加)类的成员变量或属性都是属于“修改”。
扩展一般是指在原有的架构(小一点的说是接口)基础上进行扩展。
开放封闭原则是指在现有的功能中,不修改原有的代码中进行扩展。
为符合开放封闭原则,可以利用一些设计模式来实现。
如第四副图,在原有countArea()方法需要增加输出功能。
比如可以使用适配器模式(前提是要面向接口编程)。
如下:原先的设计是定义一个接口ISqure,其定义的方法为第四副图左边类Squre包含的setLength、countArea方法。
第四副图左边类Squre实现了ISqure。
客户端调用代码:ISqure squre = new Square(); (一般不会这样直接获取对象,如通过工厂方法获取对象);double area = squre.countArea();以上是原有的设计现在需要countArea方法中还具有输出功能,如何在不修改Squre类的情况下做到呢?新建另一个类SqureImpl,同时它也实现接口ISqure,代码如下:public class SqureAdapter implements ISqure{static ISqure squre = new Squre();//原有的代码中的类Squrepublic void setLength(double length){squre.setLength(length);}public double countArea(){double area = squre.countArea();System.out.println(area); //增加输出areareturn area;}}修改客户端调用代码:ISqure squre = new SqureAdapter(); double area = squre.countArea();这样达到了不修改原有Square类,而是通过继承(扩展)接口ISqure,来增加了输出area的功能。
这样做的好处是维持了原有代码(功能)的稳定性(可能系统的代码其他地方有很多调用Square的countArea方法,这样对它们是不影响的)。
我也是最近在看面向对象设计原则的书,有问题或建议请提出来,大家共同学习。
java与模式,“对可变性的封装原则”?
一楼的回答就是“对可变性的封装原则”基本概念,这种东西还是举一个例子吧!比如“人”作为一个对象来说他是属于可变的,最起码她可以分为男人和女人,好了,我们直接上代码abstract class Person{//简单的给出了两个属性,姓名和性别protected String name="";protected String sex = "";public Person(String name,String sex){this.name = name;this.sex = sex;}/** 不管男性女性都有走路的行为* */public void run(){System.out.println(this.name+"走路");}public void eat(){System.out.println(this.name+"吃饭");}public abstract void method();}class Man extends Person{public Man(String name, String sex) {super(name, sex);System.out.println("初始化男性同胞");}/*** 这是男性特有的行为,打仗(当然女性也可以打仗,我们只假设男性会打仗)*/public void method(){System.out.println(this.name+"参加战斗");}}class Women extends Person{public Women(String name, String sex) {super(name, sex);System.out.println("初始化女性同胞");}/*** 女性有生育的行为*/public void method(){System.out.println(this.name+"生小孩");}}public class Hello{public static void main(String[] args) {Person man = new Man("zhangsan", "male");man.eat();man.run();man.method();Person women = new Women("zhangsan", "male");women.eat();women.run();women.method();}}由于person是可变的,所以我们对其进行了抽象封装,man和women分别对其进行了继承,那么我们如何让它可变呢,衍生出不同的子类就是一种可变,更严格的说就是一种扩展。
java项目软件开发 如何划分功能模块、定义模块之间接口?
先仔细理解业务的功能,做到全局掌握。
然后借助于一些建模工具,如Rose , Visio, PowerDesigner之类的,用面向对象(OO)的方法把业务涉及的主要对象建立起来,并建立他们之间的关系,你可能需要了解一些OO建模方面的知识,包括泛化、关联、组合、聚合这些常用的类之间的关系,把类之间的关系建立起来,这样慢慢的类的成员和方法就会清晰起来了。
其实一个系统建的模型可以有很多种,它们的优劣在于设计者的经验,借助于一些成熟的设计模式可以少走一些弯路,有一些普遍的准则可循,例如迪米特准则,“高内聚、低耦合”,多用组合少用继承等等,但不能为了模式而模式,归根结底还是系统能用好用。
唉,说了很多空话套话,其实你自己去实现一个系统,就会发现有很多可以改进的地方!这些原则都是在实践中掌握的!...
转载请注明出处51数据库 » 软件设计原则 软件设计模式 关系