学习大话设计模式03_单一职责原则

单一职责原则(SRP):就一个类而言,应该仅有一个能引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 如果能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.就应该考虑类的职责分离.

单一职责原则(SRP),就一个类而言,应该仅有一个引起它的变化原因. 个人认为这个原则过于理想化,仅有一个并不是绝对的,合理就好. 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离[ASD] 如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责. MVC,可以说良好运用了这个原则,但有时候一些小项目,可直接在service执行SQL语句,也是可以的. 开放-封闭原则,说是软件实体(类.模块.函数等等)应该可以扩张,但是不可修改. 对于扩张是开放的(Open for

依赖到转原则 A.高层模块不应该依赖低层模块.两个都应该依赖抽象. B.抽象不应该依赖细节.细节应该依赖抽象.即:针对接口编程,不要对实现编程. 里氏代换原则: 一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别.也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化. (子类型必须能够替换掉它们的父类型) 只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基本上增加新的行为. 由于子类型的可替换

自己之前写过一些关于设计模式的博客,但是大部分都写得比较匆忙.现在正好趁年前有时间,笔者打算好好地整理一下自己这块知识结构.开篇的第一个原则就是设计原则里面最简单的一个原则--单一职责原则. 想必大家都听过并且常用这个原则进行一些项目的重构,因为这个原则太简单了,一句话概括就是:应该有且仅有一个原因引起类的变更.但是我们在实际的项目里面不能够生搬硬套,因为单一职责原则有个缺点就是可能会造成类对象的剧增,导致我们在用的时候就需要人为的组合对象.大家应该知道组合操作就会造成冗余.耦合,所以可以视具体

单一职责原则(Single Responsibility Principle) SRP 基本概念 单一职责原则 定义:应该有且仅有一个原因引起类的变更,也就是接口或类和职责的关系是一一对应的. 难点:职责的划分: 在不同情景和生产环境下我们对职责的细化是不同的(职责单一的相对性) 单一职责原则提出的是一个评价接口是否优良的标准,但是职责和变化原因是不可度量的,因项目而异,因环境而异(不可度量性) 优势: 类的复杂性降低:每个类或接口都只实现单一的职责,定义明确清晰 可读性提高:定义明确清晰,自然

1:设计模式应用不应用,取决于对现在和未来判断后的取舍.没必要用尽量不用! 2.设计模式的目的是  减少复杂度(一个函数中包含的功能个数), 降低耦合度(一个对象与其他对象的关系个数).耦合度不能为0,越小越好,复杂度最小是1; 如一个function里,即用ajax来获取数据,又把返回数据渲染到页面,复杂度就是2,可以分开,降低复杂度必然增加至少一条关系,即增加了总体的耦合度.但个体的耦合度是1,这没有什么不好. 3复杂度的降低靠单一职责原则,开闭原则和里氏代换原则. 单一职责原则:一个函数只

单一职责原则(SRP) 定义 就一个类而言,应该仅有一个引起它变化的原因.一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离. 例子 例如在做一个根据参数对用户表进行查询再显示出来的功能,把这些东西写在一个类里面是非常不好的.如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个

面向对象的好处:可维护.可扩展.可复用.灵活性好 单一职责原则(SRP): 就一个类而言,应该仅有一个引起它变化的原因.如果有多于一个动机去改变一个类,则此类就有多于一个职责.(游戏开发中,游戏界面和游戏逻辑相分离,而不是聚合在一起) 开放封闭原则(OCP): 软件实体(类.模块.函数等)应该是可以扩展,但不可修改. 最初写代码的时候,假设变化不会发生.但当变化发生时,我们应该建立抽象来隔离以后发生的同类变化.例如,实现加法功能,放在一个单一的类中,如果此时要求实现减法功能,则应该抽象出操作类,

单一职责原则:就一个类而言,应该只有一个引起它变化的原因. 在iOS开发中,我们会很自然的给一个类添加各种各样的功能,比如随便写一个简单的应用程序,一般都会生成一个viewController类,于是我们将各种各样的代码,商业运算的算法.http请求的参数(params)封装.使用FMDB.coreData时的数据库访问语句都放在这个类里面,这就意味着,无论任何需求变化,都要来修改viewController这个类,这其实是很糟糕的,维护麻烦.复用不可能.缺乏灵活性. 也许上面说的略微夸张,因为