摘要：
接口代表的就是共同性,所谓面向接口编程,就是要抽象各种不同概念的共同点 然后把这些概念的不同点用具体的类包装起来,这样一看,面向接口编程就等于面向对象编程其实说白了是一个概念 IOC就是要把对细节的倚赖推迟到运行时,在编码期间和编译期间,完全不依赖细节 AOP就是典型的"正交性"原则指导下的应用,各... 阅读全文
摘要：
【潜水】杭州-Java-佳娃@英界尔还有一个问题我现在发现一个方法调用的深度很深如何优化啊！！ 【传说】英界尔 递归的调用? 【潜水】杭州-Java-佳娃 应该这么说：有个功能，跟其他功能依赖性太强了，如何解耦，就是每次改其他的功能都有些影响这个功能。 【传说】英界尔 把你这个功能和其他功能的依赖,用单独的接口描述出来 其他的功能模块实现这个接口 比如 A-->Func1()--->B... 阅读全文
摘要：
1，层次结构 复杂系统总是以层次结构的形式存在。复杂系统由一些子系统组成，子系统又由一些更小的子系统组成，如此下去，直到达到某种最低层次的基本组件。2，相对原本 如何划分子系统，选择哪些作为系统的基础组件相对来说比较随意，很大程度取决于观察者的判断。对一个观察者看来很基础（本原）的东西，对另一个观察... 阅读全文
摘要：
OOA,OOD,OOP三者关系OOA的分析结果可以作为OOD的需求模型OOD的设计结果作为OOP的指导蓝图OOP负责最终实现目标系统 阅读全文
摘要：
下面这一份C代码，什么样的人会写出这样的代码呢？C程序员大概不会，更有可能的是汇编程序员。 C和汇编，特别是后面的宏汇编，结构上非常相似，都是典型的过程式语言，当然没有人反对进行对象式编程，但是是做对象式编程的基础设施比较薄弱。 C和汇编，都是典型的弱类型，运行时只有地址的概念，没有类型的概念 C和汇编，都是典型的静态语言，所有的行为在编译时都已经确定，运行时不再修... 阅读全文
摘要：
测试是规格(需求),而不是测试测试就是测试,而不是规格(需求)看起来很矛盾,实际上是有道理的,我一度坚持测试就是规格(需求),我还曾经因为强力坚持测试反映需求的观念和人吵翻,现在我认识到我只看到了一面.以测试通过之前作为分界点,测试呈现两种不同的状态,我们需要以两个不同的角度去审视,这是>带给我的第... 阅读全文
摘要：
对静态语言而言 对象向外界承诺我有什么,客户端可以依赖这些承诺,它通过它的"类型"来承诺这一点 优点是: "它承诺了有的就一定有", 缺点是:"它没有承诺的就一定没有"对动态语言而言 从不向外界承诺我有什么,我随时会变,这会我是鸭子,过会就变成了一只鸡 优点是:"它有什么客户端就可以使用什么"缺点是... 阅读全文
摘要：
最强的关系: 一般与特殊的关系,在OOP里面表现为类的继承关系第二种关系: 整体与部分的关系,花瓣不是花,但是花的一部分最弱的关系: 关联关系,老师和学生有关联关系,如果去除这层关系,则就没有了任何关系 阅读全文
摘要：
AB 今天听到一朋友说,"面向对象也好 面向结构也罢,主要是减少代码冗余就可以了,不用太在乎面向对象" STST 是的,但是减少冗余不是凭空就能做到的,除了复制粘贴,还有隐藏比较深的冗余 设计模式就是提高可重用性的,没有高度的可重用性,是不可能减少荣誉的 因为这个世界上做"任何两件事",总是有相似或者相同的部分,这部分不提取出来,就是冗余 ST 相似提取不出来可以理解为不同吗 相同提不出来是冗... 阅读全文
摘要：
WB Decorator装饰器模式 Intent意图：Attachadditionalresponsibilitiestoanobjectdynamically.Decoratorsprovideaflexiblealternativetosubclassingforextendingfunctio... 阅读全文
摘要：
1,低耦合 低耦合的概念关系简单,可单独理解,测试等2,高聚合 最不希望完全无关的一些概念塞进一个包(包,类,方法)3,充分性是否完整由客户方验证,而不是一开始设计大而全,迭代过程中充实,接口最小化(只有客户需要的)4,完整性 接口应该尽可能反映该抽象概念(接口最大化),需要和充分性进行权衡,个人偏... 阅读全文
摘要：
抽象分类很难,原因有二:1,没有所谓的完美的分类抽象(尽管某些分类比另外一些更好),如果将系统划分为对象系统,那么有多少个设计人员,可能就有多少种划分方法2,明智的分类抽象需要大量的创造性思维,只有创造性思维才能在大量无关的事物之间找到共性 阅读全文
摘要：
为了概念上的完整性,系统的设计必须有一个人,最多2个人来完成,问题来了,有的人会认为,那其他人员干什么?创意都被这1-2个人垄断,剩下的实现过程就很枯燥了.实际上,经验已经表明,"没有规矩,不成方圆",最差的建筑往往是那些预算远远超标的项目,因为这些项目一开始的概念就不完整.外部的体系结构的强制性(... 阅读全文
摘要：
ATM print'hello,world' CB 。。 STST char*str="Hello,World"; templatevoidPrint(){cout()Print(){cout(); WF System.out.println("HelloWorld");CB echo"helloworld!"珍爱生命，远离c++ AB 远离java STST C++很强... 阅读全文
摘要：
过度定义需求和过度定义问题的解决方案,都是很危险的例如,在建筑蓝图上,建筑师可能指出房间中电灯开关的大概位置,但是要到装修的时,等布线工作完成之后,才能确定开关的准确位置,在建筑蓝图上指定电灯开关的准确三维位置是愚蠢的行为.过度定义在两个方面造成危害:第一,设计者关注于过于细节的问题,而无法把精力放... 阅读全文
摘要：
好的工具能做的一件事就是使不好的设计者快速创造出糟糕的设计.卓越的设计来自卓越的设计者,而不是卓越的工具.工具只是增强了个人的能力,让设计者能专注于分析或设计中真正创造i性的方面.有一些事情,工具可以做的很好,但是有一些事情,工具根本不能做. 阅读全文
摘要：
CH1 1,很多人畅谈自己就职"计算机行业","电讯行业","在线电子交易行业"时,很容易沉溺于一种假象,认为他们自己就是高科技世界里的一部分,而实际上,只有那些做基础研究,创新研究的人员才算是高科技工作者,其他人只是在运用他们的成果而已. 2,关注于具体的技术问题,是因为技术问题比非技术问题简单... 阅读全文
摘要：
1,规定对天才来说多余,对蠢才来说无效,只对中间这一部分有用(我至今没见到过天才,蠢才到是不少) 2,设计上顿悟的火花一闪而过,没有规律可循.良好的测试无法保证你在需要的时候灵感乍现,但是给人信心的良好测试和精心重构过的代码可以给你随时闪现的灵感做好迎接的准备,以便灵感一旦到来,你就能抓住她. 3,... 阅读全文
摘要：
1,隔2个月回头看自己的设计,如果感觉不好理解,那么意味着当初设计的很不合理,是需要重新设计的前兆2,快速设计实现的诱惑很大，一刻不提醒自己严格按照TDD的原则来行事，就导致复杂难以理解的设计3,难怪Kent Benck经常提醒自己，红-绿-红编码节奏，一旦脱离这个节奏，就容易被快速设计的诱惑俘虏，结果就是生产出复杂难以理解的设计4,有人说:"考虑市场和成本,这个模块将就用吧,没有时间重新... 阅读全文
摘要：
STST 这个想法认同吗？ QX 我觉得很认同 YF 赞成，但考虑重新设计要成本，特别是机会成本 QX 另外我觉得很多设计有历史局限性,当时够用，但是随着业务发展，就会不够用 STST 快速编码的诱惑很大，一刻不提醒自己严格按照TDD的原则来行事，就导致复杂难以理解的设计 QX 就是自然感受,觉得该重构了就重构,这是迭代的过程 WB 设计与实现一样，也需要不断重构，去除腐臭，持续演进。 ST... 阅读全文