软件开发设计原则

一、开闭原则

对扩展 开放 对修改关闭

1、多使用继承的方式去修改原有行为,而不是直接修改,在子类中定义拓展的方法

2、多用多态的形式,去复用(父类用virtual定义多态方法,子类用override重写方法,实例化指向子类的父类对象,调用方法就可以实现多态)

3、一个变量 我们不要直接去修改 而是用方法的形式

二、单一原则

只用一个引起变化原因,过多职责 耦合性降低 也会影响复用性

1、类、方法单一 只做一类事情

2、接口单一原则 interface(用多继承的方法继承多个接口,将接口内部方法单独,避免接口浪费)

三、迪米特原则(最小知识原则)

一个模块 或者对象尽量少于其他实体发生相互作用

1、只有对自己操作的功能部分,采用中间类对其进行变化

四、合成复用原则

一个对象里面使用一些己有的对象 或者对象组合 不要使用继承

1、多继承 关系变复杂

2、抽象一个类          Ha-a关系  Is-a关系

总结:

一个游戏分很多模块,根据单一原则,把功能模块分离清楚,每个模块下面有很多功能,每个功能要遵循迪米特原则,把不同功能分开不同脚本,方便修改。对于单个脚本,我们多使用继承方式修改,对于方法,我们多使用多态方式修改,对于变量,我们多使用方法,而不是直接修改。最后,命名规范很重要,类名:首字母大写,变量:首字母小写,其他首字母大写,遵守匈牙利命名规范。根据这些原则,定义了很多设计模式。

时间: 2024-11-06 11:32:28

软件开发设计原则的相关文章

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第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

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

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

敏捷软件开发:原则、模式与实践——第16章 对象图、第17章 用例、第18章 顺序图

第16章 对象图 有时,呈现出系统在某个特定时刻的状态是非常有用的.和一个正在运行系统的快照类似.UML对象图展示了在一个给定时刻获取到的对象.关系和属性值. 不过,你应该对花太多的对象图保持警惕.在大部分的情况下,它们都可以从相应的类图中直接推导出来,因此没有多少用处. 第17章 用例 在所有的UML图中,用例图是最令人迷惑也是最没有用处的.我建议出来系统边界外,忽略掉所有其他的图.系统边界图示例如下: 大矩形是系统边界.矩形内的所有东西都是将要开发的系统的组成部分.矩形外面是操作系统的参与者

敏捷软件开发:原则、模式与实践——第20章 咖啡的启示

第20章 咖啡的启示 这个例子对于教学有很多好处.它短小.易于理解并且展示了如何应用面向对象设计原则去管理依赖和分类关注点.但从另一方面来说,它的短小也意味着这种分离带来的好处可能抵不过其成本.就当做一个设计思路来看吧. 20.1 Mark IV型专用咖啡机20.1.1 规格说明书 Mark IV型专用咖啡机一次可以产出12杯咖啡.使用者把过滤器放置在支架上,在其中装入研磨好的咖啡,然后把支架推入其容器中.接着,使用者向滤水器中倒入12杯水并按下冲煮(Brew)按钮.水一直加热到沸腾.不断产生的

敏捷软件开发:原则、模式与实践——第9章 OCP:开放-封闭原则

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

敏捷软件开发之原则篇

1.我们最优化先要做的是通过尽早的.持续的交付有减脂的软件来使客户满意. 2.即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势. 3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好. 4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作. 5.围绕被激励起来的个人构建项目.给他们踢空所需的环境和支持,并且信任他们能够完成工作. 6.在团队内部,最距有效果并且富有效率的传递信息的方法,就是面对面的交谈. 7.工作的软件是首要的进度

敏捷软件开发:原则、模式与实践——第4章 测试

第4章 测试 编写单元测试是进行验证,更是进行设计.同样,它更是在编写文档.编写单元测试终结了许多反馈循环,尤其是功能验证方面的反馈循环. 4.1 测试驱动开发 假设我们遵循如下3条简单规则: (1)除非编写了一个不能通过的单元测试,否则不编写任何产品代码. (2)只要编写正好导致测试不通过或者编译失败的单元测试就够了,无需再多. (3)只要编写能够正好使失败的单元测试通过的商品代码就够了,无需再多. 如果遵循这些规则,我们就是以非常短的迭代周期进行工作.我们仅仅编写刚好不能通过的单元测试,接着

敏捷软件开发:原则、模式与实践——第14章 使用UML

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

敏捷软件开发:原则、模式与实践——第2章 极限编程概述

第2章 极限编程概述 作为开发人员,我们应该记住,XP并非唯一选择.--Pete McBreen,软件技术专家 在第1章中,我们概述了有关敏捷软件开发方法方面的内容,但它没有确切地告诉我们去做些什么:其中给出了一些泛泛的陈述和目标,却没有给出实际的指导方法.本章要改变这种状况. 2.1  极限编程实践 2.1.1  完整团队 我们希望客户.管理者和开发人员紧密地工作在一起,以便于彼此知晓对方所面临的问题,并共同去解决这些问题.谁是客户?XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或