OOD沉思录 --- 导引

一个对象一定会有如下4个属性:

1,它的身份标示,可能只是它在内存中的地址;

2,它的类的属性(通常是静态属性)和这些属性的值(通常是动态的);

3,它的类的行为(从实现者的角度看);

3,它的公开接口(从用户的角度看).

2.1 所有数据都应该隐藏在它所在的类内部.

考虑最简单的点Point类(X,Y),再考虑可能点的实现是用的极坐标,那么是否该领悟到这一点了?

2.2,类的使用者必须依赖类的公共接口,但类不能依赖它的使用者.

房子可以依赖闹钟,但是闹钟不能依赖房子,否则这个闹钟就不能放到别的地方了

2.3,尽量减少类的的方法的数量

几年前,部分人所提倡的原则与此正好相反,他们认为凡是能想到的,将来用户可能都能用上.

那么既然如此,那么你一定喜欢我的链表类,它的公共接口有4000个.(这里我第一次大笑)

2.4,实现所有类都能理解的最基本公共接口

如:拷贝操作(深拷贝和浅拷贝),相等性判断,正确输出内容(打印),从字符串解析等

2.5,不要把实现细节放到类的公共接口

目的是降低使用者的复杂度

2.6,用户不感兴趣的或无法使用的内容不要放到类的公共接口

与2.5类似的

2.7,类之间应该零耦合,或者只有导出耦合关系.

即:一个类要么同另一个类豪无关系,要么只使用另一个类的公共接口中的操作.

低耦合,高内聚原则

耦合:衡量两个类之间的关系.

类聚:衡量类的实现,高类聚的最理想状态是:类的所有方法都使用了其所有字段或属性,不存在一半方法使用了这一半属性或字段,而另一半方法使用了另外一半的属性或字段.     如果是这样,那这个类本身就应该被劈开为两个类.

2.8,类应当只表示一个关键抽象,反之亦然.

如果一个关键抽象被表示为多个类,则表明设计者把这个关键抽象的每个功能表示为一个类了.    反之,表明这个类表示了多个关键抽象,导致庞大复杂的类,还不好用(因为每次使用都牵扯到两个关键抽象概念)

2.9,把相关的数据和行为集中放置

否则为了满足单一的需求变更,而不得不在两个或更多的地方进行修改

2.10,把不相关的信息放到另一个类中

高类聚的原则

2.11,确保抽象的是类,而不是对象

"父亲"和"母亲"是不是类,还是某个"人"的对象?要看具体应用是否区分了这两者,如果没有区分,则表示的是对象,否则就是类.

时间: 2024-10-13 06:28:42

OOD沉思录 --- 导引的相关文章

OOD沉思录 --- 面向动作与面向对象 --- 避免泛滥成灾的类

3.7 从设计中取出不需要的类 只有Get/Set方法的类不算是一个必要的类,Get/Set方法也不算是有意义的行为.这种类降级为属性更加合适. 3.8 去除系统外部的类 如果一个类只调用系统领域的方法,而系统没有向该类调用,则可以认为这个类并不属于系统.可能只是系统的使用者,我们没必要去为此建模.     创建此类时应该问一问“这个类在系统内做什么事情?” 3.9 不要把操作变成类. “我需要一个做...事情的类”,如果有这种想法,请先认真斟酌.这个类真的代表了某个关键抽象概念吗? 名字是动词

OOD沉思录 --- 类和对象的关系 --- 使用关系原则

4.1 尽量减少类的协作的数量,即减少使用者和被使用者的数量. 协作意味着一定程度的耦合,但是完全没有协作的类也是没有意义的,最多只能作为一个库使用. 通过抽象,依赖接口,可以最大程度减少依赖的实现类,对使用者来说,只看到接口的依赖,而具体的实现的依赖可以通后后期绑定来配置依赖关系. 如 菜单 ----〉牛肉 ----〉羊肉 ----〉鸡肉       可以抽象为 菜单---->肉类 <===牛肉                       <===羊肉                 

C++沉思录之二——虚函数使用的时机

虚函数使用的时机 为什么虚函数不总是适用? 1. 虚函数有事会带来很大的消耗: 2. 虚函数不总是提供所需的行为: 3. 当我们不考虑继承当前类时,不必使用虚函数. 必须使用虚函数的情况: 1. 当你想删除一个表面上指向基类对象,实际却是指向派生类对象的指针,就需要虚析构函数. C++沉思录之二--虚函数使用的时机,布布扣,bubuko.com

个性化的亲切——《沉思录》引发的感悟

记得初中那阵子,曾经追过明星,甚至美的标准也变成了他——恨不得所有的明星都是长的和他一样,唱的和他一样.除了他的歌,我几乎欣赏不了其他人的歌. 还记得差不多在那个年纪,曾经幻想过世界“大统”——我认为“大统”是达到“大同”,消弭纷争的有效方式.惭愧,后来知道希特勒也是这么想的.此乃后话,不提. 也几乎是那个时候,我不愿再做“出头鸟”,我相信“人多力量大”,我总愿意融在身边的“圈子”,不想显得自己不合群. 个性化,在我们的应试教育体制中从来都没有得到特别的提倡,如果没有良师益友的及时提点,一定会让

迷你MVVM框架 avalonjs 沉思录 第1节 土耳其开局

#cnblogs_post_body p{ text-indent:2em; margin-top: 1em; } 正如一切传说的开端那样,有一远古巨神开天辟地,然后就是其他半神喧宾夺主.我们对最巨贡献与创建力的远古巨神懵懂不知,却对巫师们的话语津津乐道.这同样也是我们前端的现实. MVVM是来自.NET,另一个遥远的界域.前端,相对于后端,怎么看都是蛮夷之地.JS这个肩负着前端一切交互工作的语言,竟然被视为恶魔,屡屡被屏蔽禁用.些微可用的脚本,变量与函数没有组织地野蛮生长着,直到JAVA的传教

Trie树沉思录(1)

发现自己已经很久没有写解题报告了,很大一部分是因为懒,做完题之后不想再怎样了~不过最近发现写解题报告确实是有好处的,一方面可以复习,一方面可以梳理.还有就是可以给自己的岁月留下一点什么东西~今天是五一劳动节,就应该要劳动!我要重新着手写我的博客了~ 最近几个星期都在研究字符串,有点难,不过到现在为止Trie数学得还算是有那么点意思,写篇博文来记录一下! (关于Trie数是什么东西我就不想写了,我只写我个人的一些思考) Trie树通过共享前缀来达到了节约内存的目标,十分的强大!关于他的实现大概有两

PHP沉思录-第六篇-Drupal的性能问题-左轻侯-《程序员》2008年11月号

创建时间:2008-11-09 01:12:51   最后修改时间:2008-11-09 01:12:51 本文发表在<程序员>杂志2008年第11期 PHP沉思录之六:Drupal的性能问题 左轻侯 Drupal是一个基于PHP的开源CMS系统,也是我认为技术上实现得最好的一个PHP应用.Drupal的架构非常优秀,通过微内核+plugin的方式,实现了极佳的扩展性,从而使Drupal远远超出一般的CMS这一范畴.从这个意义上来说,把Drupal称为Web OS似乎更加合适一些.关于Drup

【C++沉思录】句柄2

1.[C++沉思录]句柄1 存在问题: 句柄为了绑定到Point的对象上,必须定义一个辅助类UPoint,如果要求句柄绑定到Point的子类上,那就存在问题了.2.有没有更简单的办法呢? 句柄使用Point*直接绑定到Point对象上(包括子类),为了保持多个句柄引用计数的一致性,使用int* 指向引用计数.3.代码如下:#include "point.h"class Handle_2{public: Handle_2():_p(new Point),_u(new int(1)){}

【C++沉思录】句柄1

1.在[C++沉思录]代理类中,使用了代理类,存在问题: a.代理复制,每次创建一个副本,这个开销有可能很大 b.有些对象不能轻易创建副本,比如文件2.怎么解决这个问题? 使用引用计数句柄,对动态资源封装,句柄包含指针,多个句柄可以指向同一个对象.复制的时候,只是复制句柄的指针.3.使用引用计数句柄,是为了避免不必要的对象复制,因此我们要知道有多少个句柄绑定到当前对象,也就是引用计数, 这样才能确定何时可以释放资源.4.需要注意的是:引用计数不能是句柄的一部分,如果怎么做,当前句柄必须知道指向同