OO本身就是一种大的设计模式,它是随着软件规模越来越大产生出来帮助人们建模和开发的理念,生来就带着封装.继承.多态等可复用基因.为了充分发挥这些基因的功效,使用者需要遵守一定的原则,就是所谓的面向对象设计原则.然而正确地使用这些运用这些原则并不容易,只有把这些原则吸收成为身体一部分的经验丰富的工程师才能在遇到各种问题时,灵活地使用它们.一些OO大师为了方便新手更好地理解OO原则,就根据经验假象了一些软件设计过程中经常碰到的问题,并给出了遵循OO原则的解决这些问题的设计方案,就产生了设计模式,正如…

  SOLID (面向对象设计) 基本原则    在 程序设计领域, SOLID (单一功能.开闭原则.里氏替换.接口隔离以及依赖反转)是由罗伯特•C•马丁在21世纪早期[1] 引入的记忆术首字母缩略字[2][3],指代了面向对象编程和面向对象设计的五个基本原则.当这些原则被一起应用时,它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能.[1] SOLID所包含的原则是通过引发编程者进行软件源代码的代码重构进行软件的代码异味清扫,从而使得软件清晰可读以及可扩展时可以应用的指南.S…

Todd.log - a place to keep my thoughts on programming 评OO设计 昨天在微博上看到InfoQ提供了一本新书<完美软件开发:方法与逻辑>的PDF迷你版,这本书的介绍吸引了我: 这书是培养帅才的书.如果想成为一方悍将(比如:C++高手,Android高手),那这书是不太适合的:但如果想鸟瞰全局,运筹帷幄,带领团队攻城略地,那这书是很有参考价值的. 我重点看了它的第7章“完美设计和编码之解构”,应该说这是一本好书,但是对我来说总体上没有什么新的收…

这部分增加一点自己的感想,OO设计原则下面讲述的很清晰;看完之后有点感想如果我们在实际开发当中能够把这些原则熟烂于心的话那我们的代码质量和个人能力会有很显著的提神.根据自己的实际经验看很多开发者在开发过程中很多基本的知识确实没有熟烂于心导致开发的时候只有基本的内容.我所在的项目就是代码接口各种乱,可读性和可维护性特别差:当然自己在开发的时候也都没有做到,在后面的工作中尽量避免 前面发表了5篇OO设计原则的文章,在这里我将这个5个原则如何在我们设计过程进行应用进行一下总结, 这是我通过阅读和学习很…

常用的OO设计原则: 1 封装变化:找出应用中可能需要变化之处,把它们独立出来,不要和哪些不需要变化的代码混在一起. 2 针对接口编程,而不是针对实现编程. 3 多用组合,少用继承. 4 松耦合:为了交互对象之间的松耦合设计而努力. 5 开放-关闭原则:类应该对扩展开放,对修改关闭. 6 依赖倒置:要依赖抽象,不要依赖具体类. 7 最少知识:只和你的亲密朋友交谈. 8 好莱坞原则:别调用(打电话给)我们,我们会调用(打电话给)你 9 单一责任:一个类应该只有一个引起变化的原因.…

mysql优化-数据库设计基本原则 一.数据库设计三范式 第一范式:字段具有原子性 原子性是指数据库的所有字段都不可被再次划分,如下表就不满足原子性,起点与终点 字段就可被拆分为起点与终点两个字段. id 起点-终点 1 北京-上海 2 北京-广州 第二范式:消除对主键的部分依赖 依赖是指在数据库表中,通过字段A就可以确定字段B,这就叫B对A依赖. 而部分依赖就是指当数据库表中主键为复合主键(A,C),而B仅仅对A依赖,这种情况称作部分依赖. 正确的方法是创建一个与业务逻辑无关的 id 主键,其…

今天看到个题目:对象会动态的变化. 游戏精灵,有人和神仙,但是随着人的不断积分,会升级为神仙:神仙也可能会因为积分的减少而降级为人.这种情况怎么画出个类图来. 这是第一版的设计,正常思维.人和神仙都是游戏精灵,从Is-A的角度来说是正确的.但是问题是,当人升级为神仙的时候会出现: var person=New 人(); //人升级 person=new 神仙(); 这个时候原来的人其实已经死掉了,这是不对的.第二版: 把角色抽象出来,只有一种游戏精灵,但是他的角色是不一样的,升级或者降级以后只是…

软件开发的生命周期中,数据库建模后,在某个数据库系统中形成相对应的表,之后再根据数据库模型设计相关的业务对象及其关系.这其实是进行了两次设计,一次是数据库模型设计,数据库模型设计是根据现实业务提取出来的模型,这个模型最终是产生了业务数据之间的关系以及业务数据的存储方式. 数据库建模完成后,我们需要根据数据库模型使用某一个种面向对象语言设计出对象模型,对象模型与数据库模型的区别在于对象模型主要是为了使设计过程更加面向对象,抽象.继承.多态.封装,对象模型中的实体与数据库模型中的实体可能基本一致,但…

REST四个基本原则:1.使用HTTP动词:GET POST PUT DELETE:2.无状态连接,服务器端不应保存过多上下文状态,即每个请求都是独立的:3.为每个资源设置URI:4.通过XML JSON进行数据传递: 实现上述原则的架构即可称为RESTFul架构.1.互联网环境下,任何应用的架构和API可以被快速理解:2.分布式环境下,任何请求都可以被发送到任意服务器:3.异构环境下,任何资源的访问和使用方式都统一:…

开闭原则(OCP) 里氏代换原则(LSP) 依赖倒转原则(DIP) 接口隔离原则(ISP) 合成/聚合利用原则(CARP) 迪米特法则(LOD)…