心得体会
文章平均质量分 80
heguodong
这个作者很懒,什么都没留下…
展开
-
OOD沉思录 之 类和对象的关系--包含关系4
4.9 在实现语义约束时,最好根据类定义来实现。但是这经常会导致泛滥成灾的类,在这种情况下约束应当在类的行为中实现,通常在类的构造函数中实现,但不是必须如此。 还是以汽车为例,我们看汽车的定义,为了集中注意力,先只关心汽车的发动机 class 汽车 { 汽车(发动机 para) { m_发动机=para;原创 2012-03-23 23:28:31 · 912 阅读 · 0 评论 -
OOD沉思录 之 面向动作与面向对象2--避免泛滥成灾的类
3.7 从设计中取出不需要的类 只有Get/Set方法的类不算是一个必要的类,Get/Set方法也不算是有意义的行为。这种类降级为属性更加合适。3.8 去除系统外部的类 如果一个类只调用系统领域的方法,而系统没有向该类调用,则可以认为这个类并不属于系统。可能只是系统的使用者,我们没必要去为此建模。 创建此类时应该问一问“这个类在系统内做什么事情?”3.原创 2012-03-15 07:27:21 · 518 阅读 · 0 评论 -
OOD沉思录 之 类和对象的关系--使用关系原则
4.1 尽量减少类的协作的数量,即减少使用者和被使用者的数量。 协作意味着一定程度的耦合,但是完全没有协作的类也是没有意义的,最多只能作为一个库使用。 通过抽象,依赖接口,可以最大程度减少依赖的实现类,对使用者来说,只看到接口的依赖,而具体的实现的依赖可以通后后期绑定来配置依赖关系。 如 菜单----〉牛肉 ----〉羊肉原创 2012-03-20 07:18:12 · 595 阅读 · 0 评论 -
OOD沉思录 之 类和对象的关系--包含关系1
4.5 如果类包含另一个类的对象,那么包含类应当向被包含的对象发送消息(调用方法)。 也就是说,所有的包含关系都应当是使用关系。 如果不是这样,那么包含的类有什么用处呢?当然,面向过程的开发人员会想到可能有一个Get方法供其它类使用这个包含的对象,那么按照“数据隐藏原则”,为什么不让使用包含类的类直接包含被包含的这个对象呢?包含一个对象一定是需要使用它才包含。 比原创 2012-03-20 22:53:18 · 1198 阅读 · 0 评论 -
OOD沉思录 之 类和对象的关系--包含关系2
4.6 尽量让类中定义的每个方法尽可能多地使用包含的对象(即数据成员) 这其实就是高内聚的翻版强调。如果每个类的情况并非如此,那很可能是这一个类表示了两个或更多的概念,记住一个类只应该表示一个概念。 最明显的情况就是类的一半方法使用了一半的数据成员,而另一半方法使用了另一半的数据成员,那么这个类就应该一分为二。 我们假设一个澡堂,有VIP客户和普通客户,各自有不同的服原创 2012-03-21 13:08:28 · 837 阅读 · 0 评论 -
OOD沉思录 之 类和对象的关系--包含关系3
4.7 类包含的对象数目不应当超过开发者短期记忆数量,这个数目通常应该是6左右 4.8 让系统在窄而深的包含体系中垂直分布 假设有如下两份菜单: 正餐--->甜瓜 --->牛排 --->土豆 --->豌豆 --->玉米 --->馅饼 或者 正餐--->甜瓜原创 2012-03-21 19:19:02 · 848 阅读 · 0 评论 -
OOD沉思录 之 类和对象的关系--使用关系
使用关系对象A的方法MethodA使用了B的方法MethodB,则表示A对B存在使用关系使用关系的最关键问题在于,A如何找到B,存在6种方案方案一: A包含了B,B作为一个成员定义在A的类中,那么在MethodA中可以直接调用B.MethodB() 如汽车可以包含车轮。 但是汽车需要加油,那么就需要调用"加油站B.加油()"原创 2012-03-19 21:32:35 · 717 阅读 · 0 评论 -
《The Design of Design》之 需求、罪念以及合同(合同)--《人月神话》作者之力作
任何在项目伊始就规划所有的可能需求之企图都会落败,并以客观的延误告终。-Pahl,Beitz 《Engineering Design》关于合同: 先在合同上把价格让步,然后等合同上的需求变化时再好好抬价。您有这体会吗? 希望需求,目标和约束条件早点确定下来,是形成合同的最佳需求。每个人心里都很清楚,在实施过程中,需求一定会发生变化的。合同最多只能描述几个概要的需求,原创 2012-03-19 18:19:43 · 448 阅读 · 0 评论 -
《The Design of Design》之 需求、罪念以及合同(罪念)--《人月神话》作者之力作
摘抄片段:假定: 1,客户从不索求无度,非常乐意为他的架构师和建筑工人的专业技能和辛勤劳动支付合理的费用。 2,客户聘请的代理人,渴望用自己的才华和技能帮助客户发现其真正需求所在,并竭诚服务。 3,承包方充分理解并不折不扣地按照其要求做事,并在预算和工期范围内依照最佳性价比生产高质量的产品。 4,所有的项目成员都是诚实、本分的,并且他们之间的沟通原创 2012-03-18 10:55:05 · 426 阅读 · 0 评论 -
面向对象设计的 11 原则
头五项原则是关于类设计的,它们是: ◆ SRP,单一职责原则,一个类应该有且只有一个改变的理由。 ◆ OCP,开放封闭原则,你应该能够不用修改原有类就能扩展一个类的行为。 ◆ LSP,Liskov替换原则,派生类要与其基类自相容。 ◆ DIP,依赖倒置原则,依赖于抽象而不是实现。 ◆ ISP,接口隔离原则,客户只要关注它们所需的接口。 另外的六项是关于包的设原创 2012-03-13 12:24:17 · 371 阅读 · 0 评论 -
OOD沉思录 之 继承
一,继承只应被用来为特化层次结构建模 实际上也就是要满足LSP原则,水果类<-榴莲的继承是特化二,派生类必须知道他们的基类,基类不应当知道他们的派生类 复用的前提三,基类中的所有数据都应该是私有的,不要使用保护数据(方法不在此原则约束下) 数据封装,物体的重量看起来可以用一个保护数据来表达,而不是get/set方法,但是考虑其他星球上,那么重量的应该实现为质量原创 2012-03-13 12:22:30 · 547 阅读 · 0 评论 -
OOD沉思录 之 导引
OOD沉思录 之 导引 一个对象一定会有如下4个属性: 1,它的身份标示,可能只是它在内存中的地址; 2,它的类的属性(通常是静态属性)和这些属性的值(通常是动态的); 3,它的类的行为(从实现者的角度看); 3,它的公开接口(从用户的角度看). 2.1 所有数据都应该隐藏在它所在的类内部. 考虑最简单的点Point类(X,Y原创 2012-03-13 12:21:44 · 482 阅读 · 0 评论 -
《The Design of Design》之 理性模型--《人月神话》作者之力作
理性模型 最原始也是最符合设计师第一感觉的设计方式,因为理性,所以叫理性模型:); 设计的理论即一般的搜索理论,对象是巨大的组合空间.目标: 某人想要建立一个海滨小屋,以享用面向大海的一块海滨场地的海浪.必要条件: 海滨小屋应该足够兼顾以抵御飓风; 具备至少14个人躺卧和就座的空间; 为宾原创 2012-03-13 12:23:04 · 539 阅读 · 0 评论 -
重构之美-Elcapsulate Collection(封装群集)
/*>8.11节 Elcapsulate Collection(封装群集)想到的概要: 有一个方法返回一个群集,让这个函数返回该群集的一个只读映射,并在这个类中提供添加/移除群集元素的函数。动机: 类常常使用群集(array,list,set或vector)来保存一组实体。这样的Class通常也会提供一个针对该群集的[取值/设值函数](getter/setter)原创 2009-11-30 01:47:00 · 656 阅读 · 0 评论 -
OOD沉思录 之 面向动作与面向对象1--避免全能类
面向过程的软件开发通过非常集中化的控制机制来分解功能,在程序设计中表现就是大量的条件判断,深层次的循环嵌套等。这种模式下,我们可以通过分析方法的参数,局部变量及其访问的全局变量来得到方法对数据的依赖性,但是我们只有分析整个项目代码才能得到数据对方法的依赖性。 面向对象的软件开发主要关注在非常分布的环境中分解数据以及同数据相关的功能。通过高内聚(数据与其相关行为的高度融合)和低耦合(实原创 2012-03-14 21:04:47 · 837 阅读 · 0 评论 -
《The Design of Design》之 对理性模型的批判--《人月神话》作者之力作
Wiston Royce,瀑布模型的提出人,他提出瀑布模型的本意就是用来批判的,但是现实和他闹了个笑话,多少年了大量的设计师把它奉为圣典。更加可恶的是,我们的教科书上曾经也把他视为珍宝,这些教育工作者,叫兽砖家们,该醒醒了,舔人屁股的时候先看下有没有肠炎。。。:)理性模型强调在设计的第一阶段就是把需求的内容以完整的设计树来表达,而这是不可能的。首先,我们的项目的初始阶段并不能真正知道需原创 2012-03-13 22:10:24 · 507 阅读 · 0 评论 -
《The Design of Design》之 需求、罪念以及合同(需求)--《人月神话》作者之力作
任何在项目伊始就规划所有的可能需求之企图都会落败,并以客观的延误告终。-Pahl,Beitz 《Engineering Design》 关于需求: 项目伊始,有多少需求是有技术人员参与的?有多少需求是市场人员提供的?。。。 现实中,大部分此类需求只是客户那边的管理层,各自为阵提出自己的想法。而这些想法很多只是为了表明自己分量,现实自己工作多么重要,这是我亲身原创 2012-03-16 13:35:52 · 785 阅读 · 0 评论