《设计模式之禅(第2版)》

书里文字错误太多了

世界上最难的事有两件:一是让人心甘情愿地把钱掏出来给你,二是把自己的思想灌输到别人的脑子里。

对于单一职责原则,我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

里氏替换原则为良好的继承定义了一个规范,一句简单的定义包含了4层含义。
1.子类必须完全实现父类的方法
2.子类可以有自己的个性
3.覆盖或实现父类的方法时输入参数可以被放大
4.覆写或实现父类的方法时输出结果可以被缩小

狙击手,为什么叫Snipper?Snipe翻译过来就是鹬,就是“鹬蚌相争,渔人得利”中的那只鸟,英国贵族到印度打猎,发现这个鹬很聪明,人一靠近就飞走了,没办法就开始伪装、远程精准射击,于是乎Snipper就诞生了。

子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。

证明一个定理是否正确,有两种常用的方法:一种是根据提出的论题,经过一番论证,推出和定理相同的结论,这是顺推证法;还有一种是首先假设提出的命题是伪命题,然后推导出一个荒谬、与已知条件互斥的结论,这是反证法。

注意 在Java中,只要定义变量就必然要有类型,一个变量可以有两种类型:表面类型和实际类型,表面类型是在定义的时候赋予的类型,实际类型是对象的类型,如zhangSan的表面类型是IDriver,实际类型是Driver。

人和人之间是有距离的,太远关系逐渐疏远,最终形同陌路;太近就相互刺伤。对朋友关系描述最贴切的故事就是:两只刺猬取暖,太远取不到暖,太近刺伤了对方,必须保持一个既能取暖又不刺伤对方的距离。

不知道大家有没有听过这样一个理论:“任何两个素不相识的人中间最多只隔着6个人,即只通过6个人就可以将他们联系在一起”,这就是著名的“六度分隔理论”。

Single Responsibility Principle:单一职责原则Open Closed Principle:开闭原则Liskov Substitution Principle:里氏替换原则Law of Demeter:迪米特法则Interface Segregation Principle:接口隔离原则Dependence Inversion Principle:依赖倒置原则把这6个原则的首字母(里氏替换原则和迪米特法则的首字母重复,只取一个)联合起来就是SOLID(solid,稳定的),其代表的含义也就是把这6个原则结合使用的好处:建立稳定、灵活、健壮的设计,而开闭原则又是重中之重,是最基础的原则,是其他5大原则的精神领袖。

有一个对象UserInfo存储用户的所有信息(实际系统上还有很多子类,不多说了),也就是BO(Business Object,业务对象),这个对象设计为贫血对象(Thin Business Object),不需要存储状态以及相关的关系,本人是反对使用充血对象(Rich Business Object),这里提到两个名词:贫血对象和充血对象,这两个名词很简单,在领域模型中分别叫做贫血领域模型和充血领域模型,有什么区别呢?一个对象如果不存储实体状态以及对象之间的关系,该对象就叫做贫血对象,对应的领域模型就是贫血领域模型,有实体状态和对象关系的模型就是充血领域模型。

对象适配器和类适配器的区别是:类适配器是类间继承,对象适配器是对象的合成关系,也可以说是类的关联关系,这是两者的根本区别。

组合模式有两种不同的实现:透明模式和安全模式。

在这里我们使用了一个新的设计方法:双接口设计,我们的一个类可以实现多个接口,在系统设计时,如果考虑对象的安全问题,则可以提供两个接口,一个是业务的正常接口,实现必要的业务逻辑,叫做宽接口;另外一个接口是一个空接口,什么方法都没有,其目的是提供给子系统外的模块访问,比如容器对象,这个叫做窄接口,由于窄接口中没有提供任何操纵数据的方法,因此相对来说比较安全。

说到访问者模式就不得不提一下双分派(double dispatch)问题,什么是双分派呢?我们先来解释一下什么是单分派(singledispatch)和多分派(multiple dispatch),单分派语言处理一个操作是根据请求者的名称和接收到的参数决定的,在Java中有静态绑定和动态绑定之说,它的实现是依据重载(overload)和覆写(override)实现的。
双分派意味着得到执行的操作决定于请求的种类和两个接收者的类型,它是多分派的一个特例。从这里也可以看到Java是一个支持双分派的单分派语言。

《平面国》

神作

书中是挺有贬低女性的意味,可能是维多利亚时期的关系。

从他身上吸取教训吧:自满就是丑恶和无知,渴望和抱负比蒙昧无力的快乐好得多。

向上,而不是向北。

那位圆形曾说,先知和获得天启之人总是被大众看作疯子。

若从科学技术上看,今天的世界自然比维多利亚时代的世界进步了很多。但是在其他层面上,我们是否真如我们想象的那么先进?
男性是否已经停止用“双重语言”和“双重思维” 欺骗女性?
特权阶级留给普通人的上升通道是否仍然只是允许等腰三角形变等边三角形的统治艺术?
网络真的让我们接触更多信息、鼓励我们思考了吗?还是恰恰相反,科技允许我们制作出巨大的泡泡,每天生活于其中,只与和自己观点相近的人交流?若是后者,这种所谓的“交流”与点国国王的自言自语有何不同?
我们有时觉得和自己观点不同的人低等、愚昧、不可理喻,有时只想大声咆哮、堵住别人的嘴。那样的我们是固步自封的直线国国王?还是恼羞成怒的球?
理性和求知是人类最高贵的品质。我相信, 今日世界中许多令人痛心的东西——比如分歧和对立——都不是绝症。真正能对人类造成“降维打击” 的,只有愚昧和封闭。正因如此,我们永远不应放弃思考和探索。任何一种“信仰”或“价值观”都不该成为闭目塞听、阻碍思辨的封印。
愿探索能拓宽我们的想象。愿对更高维度的渴望和追求能引领我们飞向更高的地方。

“立体人,你们是比我更高级的物种,
愿探索能拓宽你们的想象,
并孕育出最罕见、最卓越的美德—谦虚。”
——正方形

《一生何求》

《一生何求》一个家族四代人的命运狂想曲

《风雨大作》主人公毕富海。
《余生之恋》主人公毕富海儿子毕文荣。
《世界上最后一个女人》主人公毕文荣女儿毕秋杨
《大雪之下》主人公毕秋杨儿子杨意夫。
《杀夫》主人公卢琪珍,本名陈琪珍。在《余生之恋》中由陈余生和胡蕙心所生。两岁时突发高烧,由其父战友卢江海代为抚养。后怕受其父国民党飞行员身份的影响,故改名卢琪珍。

人活着,就要在不可能里相信一点可能。

《霸王别姬》

本书收录《霸王别姬》《锅炉工的妻子》两部剧作

任何一种真正意义上的英雄,都敢于战胜或是藐视不是一切也是大部分既定的法则。彻底的蔑视和战胜是不可能的,所以彻底的英雄也是不存在的。项羽有项羽的不彻底处,司马迁有司马迁的不彻底处。一般的人,通体都被链条捆绑,所以敢于蔑视成法就是通往英雄之路的第一步。

欣赏奇才,爱听奇人奇事,是人类好奇天性的表现。而当今之道德社会,树了那么多的碑,垒了那么多的墙,派了那么多的岗,安了那么多的哨,目的实际很简单:防止人类好奇。所以从某种意义上来说,所有的社会,对人类的好奇天性都是一种桎梏。当然这是没有办法的事。

《面向对象是怎样工作的》

第7-12章好像和面向对象没多大关系,内容也有点水了。

第13章(函数式语言是怎样工作的)写的不错。

面向对象的起源可以追溯到挪威的两名技术人员在1967年开发的 Simula 67 编程语言。之后,任职于美国施乐公司的艾伦•凯率领的团队开发了 Smaltalk,沿用了 Simula 67 语言的结构,确立了面向对象的概念。除此之外,凯在 IT领域还做出了很多贡献,比如开发出图形用户界面(Graphical User Interface,GUI提出作为现代笔记本电脑原型的“DynaBook设想”等。
“预测未来最好的方法就是创造它。”(The best way to predictthe future is to invent it.)据说这句名言是公司高层追问研究内容的未来走向时,凯给出的回答。想必也只有提出了诸多创新性的技术概念的凯,才能讲出这样的名言吧。

NODM 由网络(Network)、开源(Open source)、小型化(Down-sizing)和多媒体(MultiMedia)这4个单词的首字母组成“,该词在日本20世纪 90年代前半期的 IT领域广为流行。不过,随着互联网的普及,NODM 所代指的技术都逐渐成了通用技术,因此该词自然也就不再被使用了。

好莱坞原则一词可以用来表示这种框架结构的特征。在好菜坞,电影制作者对演员说“Don't call us, we will call you”(不要给我们打电话,我们会给你打电话)。

《敏捷整洁之道》

这些管理方法之所以如此失败,是因为使用它们的管理人员不理解软件项目的基本原理。这一原理被称为项目管理的铁十字,约束着所有项目必须做出权衡,无法突破。
质量、速度、成本、完成,你只能任选3个,没法4个全要。可以要求高质量、快速、低成本,这样的话项目就做不完。也可以要求低成本、快速地完成项目,那样的话质量一定不会好。

布鲁克斯定律'指出:为延迟的项目增加人手反而会使它更加延迟。

一种非常适用于大型任务的技术是三元估算。这种估算由3个数组成,这3个数分别对应最佳情况、正常情况和最坏情况。这些数都是对信心的估计:最坏情况是指你有95%的信心认为能完成该任务的时间,正常情况仅具有50%的信心,最佳情况仅具有5%的信心。

故事遵循一组简单的指导原则,这组原则的首字母缩写是 INVEST。
•|:独立(Independent)。用户故事彼此互相独立。这意味着在实现它们时不必遵守特定的顺序。例如登录不是必须在退出之前实现。
• N:可协商(Negotiable)。这是我们不在卡片上写下所有细节的另一个原因:我们希望开发人员和业务人员之间可以就这些细节进行协商。
• V:有价值(Valuable)。用户故事必须对业务具有明确且可量化的价值。
• E:可估算(Estimable)。用户故事必须足够具体,以允许开发人员进行估算。
• S:小(Small)。用户故事不应大于一到两个开发人员可以在一个选代中实现的工作量。
• T:可测试(Testable)。业务部门应该能够提出用户故事的测试标准,通过这些测试就能表明用户故事己经完成。

TDD 可以描述为以下3条简单的规则。
• 先编写一个因为缺乏生产代码而失败的测试,然后才能编写生产代码。
• 只允许编写一个刚好失败的测试——编译失败也算。
• 只允许编写刚好能使当前失败测试通过的生产代码。

肯特•贝克很久以前就提出了敏捷的4个价值观:勇气、沟通、反馈和简单。

人使用和控制工具,不能让工具控制和使用人。

分解、合并和穿刺
合并故事很简单。你可以将几张故事卡夹在一起,把它们当作一个故事对待,只需将所有故事点相加即可。
拆分故事会更有趣,因为你需要保持故事的 INVEST 原则。
穿刺是一个元故事,或者叫“用于估算故事的故事”。之所以称为穿刺,是因为我们经常需要开发一个长而很薄的切片,来打穿系统的所有层。

QA病
然而,这还不是最糟糕的。把QA工作放在流程的尾端还会带来更糟糕的问题。如果QA处于流程尾端,组织如何知道他们是否做好了自己的工作?很简单,看他们能发现多少缺陷。如果 QA 发现了很多缺陷,他们显然做得很好,QA 经理可以吹嘘自己团队发现了多少缺陷,以此作为 QA 团队尽职尽责的明确证据。
于是,发现缺陷被认为是好事。
还有谁能从这些缺陷中获益呢?老程序员有这样的说法:“你可以给我设定任何交货期限,只要别要求软件正常工作就行。”还有其他人能从缺陷中获益吗?那就是那些需要去满足交货最后期限的开发人员。
什么话都不用说,什么协议都不用写,双方都明白,他们都能从缺陷中受益。一个缺陷的“黑市经济”出现了。这种“疾病”渗透到许多组织中,哪怕暂时还不致命,这种“疾病”毫无疑问使组织逐渐虚弱。

《失业程序员日记:我在魔都跑网约车》

在豆瓣上搜索这本书没有找到
原来这本《微信读书》上的书没有出版,自然也没有ISBN,所以并没有在豆瓣上查到

感觉不像是程序员,倒像是产品经理,还是偏算法端的
书中人物臧叔有点像刘润采访过的“网约车教父”臧勤
作者非常喜欢高度地图和享快打车这两款APP

全书出现最多的一句话:“一切都是最好的安排”
充满着互联网黑话,错别字有点多
最后的结尾也太突然了

这套跑车背后的逻辑就是必须要形成接单闭环。

什么样的预约单或者首单算得上是个好单?我的答案是离家近、开得快、金额高、连环单。

有的人出生在罗马,有的人一生在通往罗马的路上。

确实从概率上来讲,不顺是必然,太顺只是偶然。

心中若有阳光,窗外便是灿烂。

只有脑力的方向正确了,体力的拼搏才会有价值。

《敏捷软件开发(珍藏版)》

从解决问题的角度讲设计模式非常好,特别是两个解决统一问题的设计模式一起讲。

有一个小错误:P67 setUp()写成了steUp()

敏捷宣言
我们一直在实践中揭示更好的软件开发方法,身体力行的同时也帮助他人。
由此,我们建立了如下价值观:
个体和互动 优先于 流程和工具
工作的软件 优先于 详尽的文档
客户合作 优先于 合同谈判
响应变化 优先于 遵循计划
也就是说,尽管右项有其价值,我们更重视左项的价值。

面向对象设计的原则
SRP 单一职责原则 就一个类而言,应该有且仅有一个引起它变化的原因。
OCP 开放-封闭原则 软件实体(类、模块和函数等)应可以扩展,但不可修改。
LSP 里氏替换原则 子类型必须能替换掉它们的基本类型。
ISP 接口隔离原则 不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。
DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该依赖于抽象。
REP 重用发布等价原则 重用的粒度就是发布的粒度。
CCP 共同重用原则 一个包中的所有类应该是共同重用的。如果重用包中的一个类,那么就要重用包中的所有类。相互之间没有紧密联系的类不应该在同一个包中。
CRP 共同封闭原则 一个包中所有的类对同一类性质的变化应该是共同封闭的。一个变化若对一个包有影响,就会影响到包中所有的类,但不会影响到其他的包造成任何影响。
ADP 无依赖原则 在包的依赖关系中不允许存在环。细节不应该有其他依赖关系。
SDP 稳定依赖原则 朝着稳定的方向进行依赖。
SAP 稳定抽象原则 一个包的抽象程度应该和其他的保持一致。

很多团队迷失在追求文档而非软件上。这通常是个巨大的错误。有条简单的规则称为“文档的马丁第一原则”,意在防止此类错误发生:
除非文档紧急且重要,否则不要写。

“大千世界,唯一稀缺的是人类的注意力。”——凯文·凯利(KK)

每个软件模块都有三项职责。第一项职责是运行所完成的功能。这是该模块得以存在的原因。第二项职责是它要应对变化。几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种改变应该尽可能简单。一个难以改变的模块是拙劣的,即便能够工作,也需要对它进行修正。第三项职责是要和读的人沟通。对该模块不熟悉的开发人员应该能够轻松地阅读并理解它。一个不能沟通的模块也是拙劣的,同样需要对它进行修正。

在 SRP 的语境中,我们把职责定义为“变化的原因”(a reason for change)。如果你有超过一个的动机去改变一个类,那么这个类就具有多种职责。有时,我们很难注意到这一点。我们习惯于以组(group)的形式去考虑职责。

许多开发人员可能会对“合理假设”的行为这一概念惴惴不安。怎样才能知道客户真正的要求呢?有一种技术可以让这些合理的假设明确下来,从而支持LSP。这种技术就是基于契约的设计(Design By Contract, DBC)。梅耶(Bertrand Meyer)对此做过阐述[Meyer1978, p.331]。
使用 DBC,类的作者明确表达出对于这个类的契约。客户端的代码可以通过契约获悉可以依赖的行为方式。契约是通过为每一个方法声明前置条件(precondition)和后置条件(postcondition)来制定的。要让一个方法得以执行,前置条件必须为真。执行完毕后,这个方法要保证后置条件为真。
按照梅耶(Meyer)的阐述,派生类的前置条件和后置条件的规则如下:
在重新声明派生类中的方法(routine,例程)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件。[Meyer97,p.573]
换句话说,当通过基类的接口使用对象时,用户只知道基类的前置条件和后置条件。
因此,派生类对象不能期望这些用户遵从比基类更强的前置条件。也就是说,他们必须接受基类可以接受的一切。同时,派生类必须和基类的所有后置条件一致。也就是说,它们的行为方式和输出不能违反基类已经确立的任何限制。基类的用户不能被派生类的输出干扰。

包的设计原则
粒度:包的内聚性原则
重用发布等价原则(REP)
可以复用的粒度就是可以发布的粒度。
共同重用原则(CRP)
在包中的类可以一起被复用。如果你复用包中的某一个类,那么就要复用包中的
所有类。
共同封闭原则(CCP)
一个包中的类对于同一类型的变化应该是共同封闭的。对于一个包的更改会影响
到该包中的所有类,而不会影响到其他包。
稳定性:包耦合性的原则
无环依赖原则(ADP)
包之间的依赖关系图中不应该存在环形。
稳定依赖原则(SDP)
向着稳定的方向依赖。
稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。