抽象与继承编程指南 - 第2页

很多权威人士，包括OO粉丝，都不喜欢“继承”，但是它让我将一个通用行为调整到特定行为时更有用和简单，只是它被误用了，像很多技术一样，需要学会如何好好地用它。众说纷纭：1. 我默认使用组合，并且如果在重复几次之后有意义时才使用继承。

站在任何街角，观看交通一段时间，来来往往都是汽车。它们具有相同的基本结构：四个轮子，一个发动机，一个方向盘，用汽油或柴油运行。然而，它们在颜色，马力，形状，特征甚至可能使用的汽油类型方面差异很大。每条繁忙的街道都是不同车型的杂音，但我们看到的大多数车辆，每个人都会同意，是一辆汽车。是的，根据

一位有着10年面向对象语言的程序员对面向对象两大支柱继承和封装提出了自己的疑问，并由此认为可以向面向对象说再见了。原文：

文档是包含许多属性的对象，而属性可以是数字或字符串之类的值，也可以是其他文档的列表。使用键Key引用每个属性。当遍历文档树时，用户指定用于创建下一级别的实现类的构造函数。这些实现通常是扩展Document接口的各种特性的联合，使它们可以自己处理设置和获取属性。

重复是比错误的抽象更便宜。看到重复事物，我们总是试图从重复中抽象出共同点，这其实属于过度设计，反而给代码带来更高的维护拓展成本。 duplication is far cheaper than the wrong abstraction

简单地说，交集类型是通过组合至少两种不同类型而创建的匿名类型的形式。想象一下，我们需要模拟两种类型的动物：那些可以飞的那些可以游泳的我们可以简单地实现两个接口:

此模式属于对象关系结构模式目录，此目录属于企业应

任何优雅对象的类必须是抽象的或final的，我相信，这条规则背后的意图是消除继承。继承的缺点和子类型的缺点是相当清楚的，所以我不会在这里强调，然而，在我的实践中，我很快意识到这条规则出了问题。比如下面案例来自

如果有人问我“在所有软件开发中最重要的概念是什么？” 我会用一个词来回答它：“抽象”。抽象就是将一个想法简化为绝对本质。让我们看一个例子：运行这个活动，如果你仔细看看你跑步时身体实际发生了什么，你的头

EntityGraphs和JOIN FETCH子句提供了一种简单有效的方法来获取实体并初始化其关联。但是，如果尝试将其与

目的实现无类型语言的灵活性并保持类型安全

复制比错误的抽象便宜得多（代价小成本低），宁可重复而不选择错误的抽象。让人们意识到“错误的抽象”这个问题是很难：程序员A看到重复。程序员A提取重复并为其命名。这创建了一个新的抽象。它可能是一种新方法，甚至可能是一种新类。程序员A用新的抽象

我已经用Java编程超过五年了，并且认为我知道重载和覆盖是如何工作的。只有一次我开始思考并写下以下的角落案例，我才意识到我几乎不知道它。为了游戏化这些细微差别，我在下面将它们列为一系列谜题。单一分发假设有

Java 8 Lambda表达式的简洁性为经典的GoF设计模式提供了新的视角。通过利用函数式编程，我们可以通过更少的耦合和仪式获得相同的好处 - 模板方法就是一个很好的例子。经典的GoF模板方法实现模板方

目的预计将来需要扩展对象的接口。其他接口由扩展对象定义。

“ 不要重复自己 DRY”，每个开发者都在他职业生涯的早期就学会了这个口头禅。对这个原则的共同理解是你不应该复制你的代码。就那么简单。不要复制，如果你发现重复就重构。违反此规则的行为将被其他开发人员立即指出为侵犯软件开发最基本的做法之一。

这篇文章认为接口interface代表的间接和abstract代表的抽象并不是一回事，间接是为了分离，松耦合，而抽象是为了将细节剥离。这是软件设计中两个不同维度。然后他谈了这两种情况的四个组合：没有间接但是又抽象，也就是直接但抽象，他以Strin

我之前写过关于抽象成本的文章。一旦你在IT行业工作了几十年，一旦你在遗留代码上阅读了数百万行，你就会对任何一种抽象产生正常的怀疑。并不是说我们可以不做抽象。我们需要它能够