这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。


当前回答

并不是所有的程序员都生而平等

管理人员经常认为DeveloperA == DeveloperB仅仅是因为它们具有相同的经验水平等等。事实上,一个开发人员的性能可能是另一个开发人员的10倍甚至100倍。

谈论它在政治上是有风险的,但有时我想指出,即使几个团队成员可能看起来具有相同的技能,但情况并不总是如此。我甚至见过这样的情况:首席开发人员“毫无希望”,而初级开发人员承担了所有实际工作——尽管如此,我还是确保他们得到了荣誉。:)

其他回答

有时,接受一个异常是合适的。

对于UI来说,用错误消息提示用户是中断的,通常他们也没什么可做的。在这种情况下,我只是记录它,并在日志中出现时处理它。

最好的代码通常不是你写的。作为程序员,我们希望通过编写一些很酷的方法来解决每个问题。任何时候,我们都能在解决问题的同时满足用户80%的需求,而无需引入更多代码进行维护和测试,我们已经提供了更多的价值。

罗布·派克写道:“数据占主导地位。如果你选择了正确的数据结构,并且组织得很好,算法几乎总是不言而喻的。数据结构,而不是算法,才是编程的核心。”

由于现在任何重要的数据都在数百万条记录中,我认为良好的数据建模是最重要的编程技能(无论是使用rdbms还是sqlite或amazon simpleDB或谷歌appengine数据存储)。

当所有的数据都存储在这样的数据存储系统中时,就不再需要花哨的搜索和排序算法了。

好吧,我说过我会更详细地阐述我的“密封类”观点。我想有一种方法可以展示我感兴趣的答案,那就是给我自己一个答案:)

意见:在c#中,默认情况下类应该是密封的

推理:

There's no doubt that inheritance is powerful. However, it has to be somewhat guided. If someone derives from a base class in a way which is completely unexpected, this can break the assumptions in the base implementation. Consider two methods in the base class, where one calls another - if these methods are both virtual, then that implementation detail has to be documented, otherwise someone could quite reasonably override the second method and expect a call to the first one to work. And of course, as soon as the implementation is documented, it can't be changed... so you lose flexibility.

C# took a step in the right direction (relative to Java) by making methods sealed by default. However, I believe a further step - making classes sealed by default - would have been even better. In particular, it's easy to override methods (or not explicitly seal existing virtual methods which you don't override) so that you end up with unexpected behaviour. This wouldn't actually stop you from doing anything you can currently do - it's just changing a default, not changing the available options. It would be a "safer" default though, just like the default access in C# is always "the most private visibility available at that point."

通过让人们明确表示他们希望人们能够从他们的类中派生,我们将鼓励他们更多地思考这个问题。这也可以帮助我解决我的懒惰问题——虽然我知道我应该密封几乎所有的类,但我很少真的记得这样做:(

对方观点:

我可以看到这样一种说法:可以相对安全地派生没有虚方法的类,而不需要额外的灵活性和通常需要的文档。目前我不确定如何应对这个问题,只能说我相信意外打开类的危害比意外密封类的危害更大。

单身人士并不邪恶

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.