这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为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这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。
顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。
getter和setter被过度使用
我见过数百万人声称公共字段是邪恶的，所以他们将它们设置为私有字段，并为所有这些字段提供getter和setter。我相信这与公开字段几乎是一样的，如果你使用线程(但通常不是这样)或如果你的访问器有业务/表示逻辑(至少有些“奇怪”)，可能会有点不同。
我不赞成公共字段，但反对为每个字段创建getter/setter(或Property)，然后声称这样做是封装或信息隐藏……哈!
更新:
这个答案在评论中引起了一些争议，所以我会试着澄清一下(我不会动原文，因为这是许多人点赞的)。
首先，任何使用公共场地的人都应该坐牢
现在，创建私有字段，然后使用IDE为每个私有字段自动生成getter和setter，几乎和使用公共字段一样糟糕。
很多人认为:
私有字段+公共访问器==封装
我说(自动或非自动)为字段生成getter/setter对有效地违背了您试图实现的所谓封装。
最后，让我引用Bob叔叔在这个主题中的一句话(摘自“干净代码”的第6章):
我们保持沉默是有原因的 私有变量。我们不想要 没有人可以依靠他们。我们想要的 自由地改变他们的类型或者 心血来潮地执行 冲动。那么，为什么要这么多呢 程序员会自动添加getter 和对象的setter，暴露 他们的私人领域，就好像他们是 公众吗?
关系数据库是在浪费时间。改用对象数据库!
关系数据库供应商试图欺骗我们，让我们相信世界上唯一可扩展的、持久的和安全的存储就是关系数据库。我是一个认证的DBA。你是否曾经花了几个小时试图优化一个查询，却不知道哪里出了问题?关系数据库不允许您在需要时创建自己的搜索路径。你把应用速度的控制权拱手让给了素未谋面的人，他们并不像你想象的那么聪明。
当然，有时在维护良好的数据库中，他们会为复杂的查询提供快速答案。但你为此付出的代价太高了!每次要读取数据项时，都必须选择编写原始SQL，这是很危险的。或者使用Object关系映射器，这会增加更多的复杂性和超出你控制的事情。
更重要的是，你被禁止提出智能搜索算法，因为每次该死的往返数据库花费你大约11毫秒。这太过分了。想象一下，您知道这个超级图算法，它将回答一个特定的问题，这个问题甚至可能无法用SQL表达!，在适当的时候。但是，即使您的算法是线性的，而有趣的算法不是线性的，也不要将它与关系数据库结合起来，因为枚举一个大表将花费您数小时!
将其与SandstoneDb或Gemstone for Smalltalk进行比较!如果你喜欢Java，试试db4o吧。
因此，我的建议是:使用对象- db。当然，它们并不完美，有些查询速度会比较慢。但是你会惊讶的发现很多人会更快。因为加载对象不需要在SQL和域数据之间进行所有这些奇怪的转换。如果您确实需要某个查询的速度，对象数据库有您应该信任的查询优化器:您的大脑。
单身人士并不邪恶
There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Addtionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.
使用存储过程
除非您正在编写由不可重用的SQL查询组成的大型过程函数，否则请将数据库的存储过程移到版本控制中。
