设计模式(2):两条原则

单一职责原则:就一个类而言,应该仅由一个引起它变化的原因。[SRP]

如MVC框架,就是把界面设计、逻辑设计、数据设计的职责分开的典型案例。这是面向对象开发的一条基本原则吧。

开放封闭原则:软件实体(类、模块、函数等)可以扩展,但不可修改。[ASD]

即对扩展开放、对更改封闭。需求总是不断变化的,所以代码也总是要变化。但是应该做到:增加新代码,而不修改原代码。

所以要求尽早识别出代码中容易变化的部分,然后创造抽象来隔离这些变化。

这两条原则应该是所有设计模式最核心的原则。尤其是第二条ASD,实现了可维护、可扩展、可复用、灵活性好。

时间: 2024-11-10 13:31:26

设计模式(2):两条原则的相关文章

设计模式之6大原则(5)-迪米特法则

迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简写LKP),就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话.英文简写为: LoD. 迪米特法则可以简单说成:talk only to your immediate friends. 对于面向OOD来说,又被解释为下面几种方式:一个软件实体应当尽可能少的与其他实体发生相互作用.每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位. 迪米特

设计模式之6大原则

好久没有更新博客了,一个自己这段时间忙于项目:另外一个原因就是自己这段时间干了一件美满的事情,找到了人生的另一半(虽然现在还是女朋友阶段):但是我还是希望能够有足够的时间.心情能够将自己这段时间的一些收获用文字的形式记录下来: 说到设计模式,其实大家都不陌生,应该说都是非常熟悉的.因为在项目里面都会不知不觉的用到它们,我想最耳熟能详的单例模式,大家应该都是熟悉的“不要不要”的吧.但是如果我问你,在设计模式里面有6条最基本的设计原则,你知道是哪些吗? 单一职责原则,这条原则大家望文生义就应该知道它

设计测试用例的四条原则

今天是2011年的第一天,2010年就这样匆匆忙忙,紧紧张张地过去了.这一年里来来去去,变化最大的就是很多一起工作了多年的同事离开了,很多都去了"更给力”的地方,呵呵!公司里来来往往是很正常的,想想我最近一次换到“更给力”的地方,那都是5年前了.总之,现在的地方还是挺给力的,好好工作,争取2011年有更大的进步,呱唧呱唧! 测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解.明确测试范围(特别是要

【tool】设计测试用例的四条原则

测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解.明确测试范围(特别是要明确哪些是不需要测试的).具备基本的测试技术(如:等价类划分等)等.那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案:在理论上是,但在实际工程中还远远不是.之所以理论和实际会有这样的差别,是因为在理论上不要考虑 测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一

防御 XSS 的七条原则

本文将会着重介绍防御XSS攻击的一些原则,需要读者对于XSS有所了解,至少知道XSS漏洞的基本原理,如果您对此不是特别清楚,请参考这两篇文章:<Stored and Reflected XSS Attack><DOM Based XSS> 攻击者可以利用XSS漏洞向用户发送攻击脚本,而用户的浏览器因为没有办法知道这段脚本是不可信的,所以依然会执行它.对于浏览器而言,它认为这段 脚本是来自可以信任的服务器的,所以脚本可以光明正大地访问Cookie,或者保存在浏览器里被当前网站所用的敏

C#使用设计模式和软件设计原则构建应用程序 PartIII

依赖注入 这个原则的要点是什么.为什么你不能对类的实例进行再次硬编码?当我们编码,测试的时候,让我们关注一件很重要的事情.希望你知道单元测试并知道它的重要性.也许在你做任何编码之前你都应该首先设计你的测试,因此你应该很熟悉测试驱动开发.为了定义新功能你应该去写测试,你应该尝试去实现并开始编码直到测试通过.让我们先看看之前的文章的代码. public class DateBasedTaxFactory:ITaxFactory { Customer _customer; ITaxFactory _t

学习Java设计模式的10条建议

设计模式在整个Java的学习路线图中扮演着承上启下的作用. 在整个软件生命周期中,唯一不变的就是变化.设计模式就是要在软件设计.编码中对现有问题的一种总结,并从中寻求应对变化的策略. 自己初次接触设计模式有以下几个感觉: 内容很抽象. 示例都能看得懂,但不知道实际中如何应用. 不理解为什么要把“好好的程序”设计成这么复杂? 转眼之间到了需要自己参与需求分析.设计,并且维护之前留下的遗产代码(Legacy Code)的时候了. 再次开始学习设计模式,有了新的收获: 站在变化的角度去看,设计模式虽然

防御XSS攻击的七条原则

本文将会着重介绍防御XSS攻击的一些原则,需要读者对于XSS有所了解,至少知道XSS漏洞的基本原理,如果您对此不是特别清楚,请参考这两篇文章:<Stored and Reflected XSS Attack><DOM Based XSS> 攻击者可以利用XSS漏洞向用户发送攻击脚本,而用户的浏览器因为没有办法知道这段脚本是不可信的,所以依然会执行它.对于浏览器而言,它认为这段脚本是来自可以信任的服务器的,所以脚本可以光明正大地访问Cookie,或者保存在浏览器里被当前网站所用的敏感

设计模式之六大设计原则

在上篇博文中提到了开放-封闭原则,没有细谈,这次我们来总结一下设计模式的几大原则. 1开放-封闭原则:是指软件实体(类.模块.函数等)应该可以扩展,但是不可修改. 对原则的理解:开闭原则是最具有理想主义色彩的一个原则,它是面向对象设计的终极目标,下面所要介绍的几个原则可以看成是为了符合开闭原则所作的努力和解决办法.对于开闭原则通俗的理解就是,能不改就不改,能少改尽可能的少改.周所周知,物质是运动的,世界是变化的,想要让一个事物永恒不变是不可能的,所以要想让软件绝对符合开闭原则是不可能的. 2单一