面向对象编程被过度使用

有时候最好的答案就是简单的答案。

扩展方法是魔鬼的工作

Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).

主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。

I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.

LINQ是这样设计的，链式方法调用是必要的，以避免奇怪和不舒服的表达式，来自LINQ的扩展方法是可以理解的，但一般来说，链式方法调用降低了可读性，并导致我们在混乱的Perl竞赛中看到的那种代码。

因此，简而言之，扩展方法是邪恶的。摆脱撒旦的枷锁，致力于自由扩展代码。

如果以后可以节省3倍的时间，那就只写抽象。

有时我看到人们写出这些疯狂的抽象概念，我就会想:“为什么?”

除非抽象真的能在以后节省你的时间，或者它能节省维护你代码的人的时间，否则人们似乎只是越来越多地编写意大利面条式的代码。

观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。

绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。

当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和x-to-x关系)对系统的其余部分建模时，我们将整个应用程序限制为如何在数据库中存储数据和如何从数据库中检索数据。此外，我们将数据库体系结构公开给软件。

数据库模式是一个实现细节。我们应该可以自由地改变它，而不需要对我们的软件设计进行任何显著的改变。业务层不应该知道表是如何设置的，或者是从视图中提取还是从表中提取，或者是从动态SQL或存储过程中获取表。这种类型的代码永远不应该出现在表示层中。

软件是用来解决业务问题的。我们要处理用户、汽车、帐户、余额、平均值、摘要、转账、动物、消息、包裹、购物车、订单和其他各种真实的有形对象，以及我们可以对它们执行的操作。我们需要根据需要保存、加载、更新、查找和删除这些项。有时候，我们必须以特殊的方式来做这些事情。

But there's no real compelling reason that we should take the work that should be done in the database and move it away from the data and put it in the source code, potentially on a separate machine (introducing network traffic and degrading performance). Doing so means turning our backs on the decades of work that has already been done to improve the performance of stored procedures and functions built into databases. The argument that stored procedures introduce "yet another API" to be manged is specious: of course it does; that API is a facade that shields you from the database schema, including the intricate details of primary and foreign keys, transactions, cursors, and so on, and it prevents you from having to splice SQL together in your source code.

把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。

关系数据库是在浪费时间。改用对象数据库!

关系数据库供应商试图欺骗我们，让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询，却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人，他们并不像你想象的那么聪明。

当然，有时在维护良好的数据库中，他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时，都必须选择编写原始SQL，这是很危险的。或者使用Object关系映射器，这会增加更多的复杂性和超出你控制的事情。

更重要的是，你被禁止提出智能搜索算法，因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下，您知道这个超级图算法，它将回答一个特定的问题，这个问题甚至可能无法用SQL表达!，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要将它与关系数据库结合起来，因为枚举一个大表将花费您数小时!

将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java，试试db4o吧。

因此，我的建议是:使用对象- db。当然，它们并不完美，有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度，对象数据库有您应该信任的查询优化器:您的大脑。

getter和setter被过度使用

我见过数百万人声称公共字段是邪恶的，所以他们将它们设置为私有字段，并为所有这些字段提供getter和setter。我相信这与公开字段几乎是一样的，如果你使用线程(但通常不是这样)或如果你的访问器有业务/表示逻辑(至少有些“奇怪”)，可能会有点不同。

我不赞成公共字段，但反对为每个字段创建getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈!

更新:

这个答案在评论中引起了一些争议，所以我会试着澄清一下(我不会动原文，因为这是许多人点赞的)。

首先，任何使用公共场地的人都应该坐牢

现在，创建私有字段，然后使用IDE为每个私有字段自动生成getter和setter，几乎和使用公共字段一样糟糕。

很多人认为:

私有字段+公共访问器==封装

我说(自动或非自动)为字段生成getter/setter对有效地违背了您试图实现的所谓封装。

最后，让我引用Bob叔叔在这个主题中的一句话(摘自“干净代码”的第6章):

我们保持沉默是有原因的 私有变量。我们不想要 没有人可以依靠他们。我们想要的 自由地改变他们的类型或者 心血来潮地执行 冲动。那么，为什么要这么多呢 程序员会自动添加getter 和对象的setter，暴露 他们的私人领域，就好像他们是 公众吗?