设计原则记录

  以下内容均来自互联网:

  1. Identify the aspects of your application that vary and separate them from what stays the same.(找到系统中变化的部分,将变化的部分同其它稳定的部分隔开。)换句话说就是:“找到变化并且把它封装起来,稍后你就可以在不影响其它部分的情况下修改或扩展被封装的变化部分。” 尽管这个概念很简单,但是它几乎是所有设计模式的基础,所有模式都提供了使系统里变化的部分独立于其它部分的方法。
  2. Program to an interface, not an implementation.(面向接口编程,而不要面向实现编程。)
    “接口”这个词已经被赋予太多的含义,搞的大家一说点儿屁事就满嘴往外蹦“接口”。那么它到底是什么意思呢?我们这里说的接口是一个抽象的概念,不局限于语言层面的接口(例如C#里的interface)。一个接口也可以是一个抽象类,或者一个基类也可以看作是一种接口的表现形式,因为基类变量可以用来引用其子类。要点在于,我们在面向接口编程的时候,可以使用多态,那么实际运行的代码只依赖于具体的接口(interface,抽象类,基类),而不管这些接口提供的功能是如何实现的,也就是说,接口将系统的不同部分隔离开来,同时又将它们连接在一起。
  3. Favor composition over inheritance.(优先使用对象组合,而非类继承)
    关于组合和继承,我们只要这样来理解即可:组合是一种“HAS-A”关系,而继承是一种“IS-A”关系。很明显“HAS-A”要比“IS-A”更灵活一些。也就是说在创建系统的时候,我们应该优先使用对象组合,因为它不仅可以给你提供更多灵活性和扩展性,而且还使你可以在运行时改变行为(组合不同的对象),这简直是酷毙了!但是也不是说继承就是不能用,只是说应该把继承应用在相对更稳定,几乎没有变化的地方,例如前面的Duck类里的Swim()方法,因为可以肯定所有鸭子一定都会游泳,所以就没有必要给这个行为提供基于Strategy模式的实现方式,因为那样做除了是程序更复杂以外,没有什么意义。
  4. “Software entities should be open for extension,but closed for modification”(软件实体应当对扩展开放,对修改关闭)具体是策略模式。
  5. “Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”(继承必须确保超类所拥有的性质在子类中仍然成立)也就是说,当一个子类的实例应该能够替换任何其超类(父类)的实例时,它们之间才具有is-A关系。

如果以后继续补充

时间: 2024-11-04 19:46:12

设计原则记录的相关文章

面向对象设计原则

七大原则:开闭原则.里氏代换原则.依赖倒转原则.合成/聚合复用原则.迪米特法则.接口隔离原则,单一职责原则. 开闭原则是面向对象的可复用的基石.其他六种原则是手段和工具. 各规则详细(本部分为转载) http://kb.cnblogs.com/page/214010/ 正如牛顿三大定律在经典力学中的位置一样,“开-闭”原则(Open-Closed Principle)是面向对象的可复用设计(Object Oriented Design或OOD)的基石.其他设计原则(里氏代换原则.依赖倒转原则.合

SoC嵌入式软件架构设计之三:代码分块(Bank)设计原则

上一节讲述了在没有MMU的CPU(如80251.MIPS M控制器系列.ARM cortex m系列)上实现虚拟内存管理的集成硬件设计方法,新设计的内存管理管理单元要实现虚拟内存管理还需要操作系统.代码分块(Bank)的支持,详见SoC嵌入式软件架构设计之二:没有MMU的CPU实现虚拟内存管理的设计方法.这里要阐述Bank设计的一些原则. Bank设计是为了实现不同时刻运行的Bank(代码块)运行在同一块内存上,所以在运行之前操作系统需要将已存在内存的代码/数据进行缓存处理,并加载将要运行的Ba

规范化-数据库设计原则

关系数据库设计的核心问题是关系模型的设计.本文将结合具体的实例,介绍数据库设计规范化的流程. 摘要 关系型数据库是当前广泛应用的数据库类型,关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计.对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构.然而,随着项目规模的不断增长,相应的数据库也变得更加复杂,关系模型表结构更为庞杂,这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的.更糟糕的是,由于表结构定义的不合理,会导致在更新数据时造成数据的不完整.

面向设计原则理解

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 面向对象设计(OOD)核心原则让我的程序模块达到"高内聚低耦合",这是来自于30年前兴起的结构化设计(structured Design),但是同样适用于我们的OOD. 1.高内聚: 高内聚是指某个特定模块(程序,类型)都应完成一系列相关功能,描述了不同程序,类型中方法,方法中不同操作描述的逻辑之间的距离相近.高内聚意味可维护性,可重新性,因为模块对外部的依赖少(功能的完

RESTful API的设计原则

最近一直在做公司的一个API平台的项目,前后大约有半年多了,中间穿插了好多其他的项目一起做的.上周经理要求写文档,我就重新打开项目开始检阅之前的代码,发现好多地方当初设计的并不合理,忽然就想到,一个好的API平台,应该怎么来设计呢?有哪些规范要遵守呢?面对自己的项目,感觉好多地方都要改,但是已经有人在用了,怎么办?全都要改动吗?所以就上网找解决方案,然后就发现一精品贴,现转载过来,以备不时查阅. 原文地址:http://www.cnblogs.com/moonz-wu/p/4211626.htm

设计模式之6大设计原则

设计模式之6大设计原则 原则一:单一职责原则(Single Responsibility Principle SRP) 定义:There should never be more than one reason for a class to change.(应该有且仅有一个原因引起类的变更) 好处: 1.类的复杂性降低,实现什么职都有清晰明确的定义: 2.可读性高,负责性降低,当然可读性就提高了: 3.可维护性提高,可读性提高,自然就更容易维护了: 4.变更引起的风险降低,变更是必不可少的,如果

mysql web数据库的设计归范-2表设计原则

[职责分离原则] 职责分离原则是指在设计的时候应当考虑到数据的产生,聚合使用等原则,每个系统干自己能干的事情,每个系统只干自己的事情.一个数据表应该放在哪个系统中,通常取决于几点: 1. 谁产生这个信息:通常情况下谁产生了这个数据应当对此数据负责:也就是考虑该数据的创建,发展,销毁等全生命周期的定义,并将这个定义维护起来提供给消费者作为消费原则: 2. 谁最经常使用这个信息:如果某个系统最经常使用这个数据,最经常去修改某个数据,也应该由该系统来负责保存维护该数据: 3. 遵守高内聚,低耦合的考虑

好RESTful API的设计原则

说在前面,这篇文章是无意中发现的,因为感觉写的很好,所以翻译了一下.由于英文水平有限,难免有出错的地方,请看官理解一下.翻译和校正文章花了我大约2周的业余时间,如有人愿意转载请注明出处,谢谢^_^ Principles of good RESTful API Design 好RESTful API的设计原则 Good API design is hard! An API represents a contract between you and those who Consume your da

数据库设计原则(二)

1. 原始单据与实体之间的关系  可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.    这就是“一张原始单证对应多个实体”的典型例子. 2. 主键与