这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
程序员应该不惜一切代价避免通过继承隐藏方法。
In my experience, virtually every place I have ever seen inherited method hiding used it has caused problems. Method hiding results in objects behaving differently when accessed through a base type reference vs. a derived type reference - this is generally a Bad Thing. While many programmers are not formally aware of it, most intuitively expect that objects will adhere to the Liskov Substitution Principle. When objects violate this expectation, many of the assumptions inherent to object-oriented systems can begin to fray. The most egregious cases I've seen is when the hidden method alters the state of the object instance. In these cases, the behavior of the object can change in subtle ways that are difficult to debug and diagnose.
Ok, so there may be some infrequent cases where method hiding is actually useful and beneficial - like emulating return type covariance of methods in languages that don't support it. But the vast majority of time, when developers use method hiding it is either out of ignorance (or accident) or as a way to hack around some problem that probably deserves better design treatment. In general, the beneficial cases I've seen of method hiding (not to say there aren't others) is when a side-effect free method that returns some information is hidden by one that computes something more applicable to the calling context.
像c#这样的语言通过要求在隐藏基类方法的方法上使用new关键字进行了一些改进——至少有助于避免非自愿地使用方法隐藏。但我发现许多人仍然混淆了new和override的含义——特别是在简单的场景中，它们的行为看起来是相同的。如果像FxCop这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。
顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。
其他回答
编程:这是一份有趣的工作。
我似乎看到了两类开发人员。有些人不喜欢，但他们有能力，薪水也不错。另一组人喜欢它的程度有点令人毛骨悚然。这似乎就是他们的生活。
我只是觉得这份工作薪水高，而且有趣。每一天的每一分钟都有各种各样的学习新东西的空间。我想不出其他我更喜欢的工作了。但这仍然是一份工作。妥协是要做出来的，你生产的东西并不总是那么好。
因为我更愿意在沙滩上喝啤酒或和孩子们一起玩。
观点:数据驱动的设计本末倒置。它应该立即从我们的思想中消除。
绝大多数软件不是关于数据的，而是关于我们试图为客户解决的业务问题。它是关于一个问题域的，涉及对象、规则、流程、案例和关系。
当我们从数据开始设计，并根据数据和数据之间的关系(表、外键和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.
把马放回马车前面。思考问题领域，并围绕它设计解决方案。然后，从问题域导出数据。
根据我得到的大量反馈，我最具争议的观点显然是，程序员并不总是读他们声称读过的书。这紧跟着我的观点，一个受过正规教育的程序员比一个自学成才的程序员更好(但不一定比另一个自学成才的程序员更好)。
其中一个我已经琢磨了很久了:
数据就是系统。
流程和软件是为数据构建的，而不是相反。
没有数据，过程/软件就没有什么价值。没有流程或软件，数据仍然有价值。
一旦我们理解了数据，它是做什么的，它是如何相互作用的，它在不同阶段以不同的形式存在，只有这样才能构建一个解决方案来支持数据系统。
成功的软件/系统/过程似乎有一个敏锐的意识，如果不是狂热的正念，在任何给定的时刻数据在“哪里”。
分页从来不是用户想要的
If you start having the discussion about where to do pagination, in the database, in the business logic, on the client, etc. then you are asking the wrong question. If your app is giving back more data than the user needs, figure out a way for the user to narrow down what they need based on real criteria, not arbitrary sized chunks. And if the user really does want all those results, then give them all the results. Who are you helping by giving back 20 at a time? The server? Is that more important than your user?
[编辑:基于评论的澄清]
作为一个真实世界的例子，让我们看看这个Stack Overflow问题。假设我有一个有争议的编程观点。在我发帖之前，我想看看是否已经有了一个解决相同观点的答案，这样我就可以给它投票了。我唯一的选择就是点击每一页的答案。
我更喜欢以下选择之一:
请允许我搜索答案(这是一种根据实际标准缩小我需要的范围的方法)。 允许我看到所有的答案，这样我就可以使用浏览器的“查找”选项(给我所有的结果)。
如果我只是想找到以前读过的答案，但再也找不到了，也可以这样做。我不知道它是什么时候发布的，也不知道它有多少选票，所以排序选项没有帮助。即使我找到了，我仍然需要玩猜谜游戏来找到正确的结果页面。事实上，答案是有页码的，我可以直接点击进入十几个页面中的一个，这一点帮助都没有。
-- bmb
