程序员应该不惜一切代价避免通过继承隐藏方法。

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这样的工具实际上有内置的规则来识别方法隐藏的潜在不良使用，那就太好了。

顺便说一下，通过继承隐藏方法不应该与其他类型的隐藏(例如通过嵌套)相混淆，我认为嵌套是一种有效且有用的构造，潜在问题较少。

关系数据库系统将是自切片面包以来最好的东西……

．.． 那就是当我们(希望)得到它们的时候。SQL数据库太糟糕了，一点都不好笑。

我觉得有趣的是，认证dba认为SQL数据库系统是关系数据库系统。这说明了上述认证的质量。

困惑吗?读c·j·戴特的书。

edit

为什么叫关系?这个词是什么意思?

如今，拥有强大(哎呀，任何)数学背景的程序员(或认证DBA, wink)是例外，而不是常见情况(我也是常见情况的一个实例)。SQL的表、列和行，以及被称为实体/关系建模的笑话，只是在伤害上加了侮辱。难怪有一种误解，认为关系数据库系统之所以这样叫，是因为实体(表)之间的某些关系(外键?)是如此普遍。

事实上，关系源于关系的数学概念，因此与集合理论和函数密切相关(在数学意义上，而不是任何编程意义上)。

[http://en.wikipedia.org/wiki/Finitary_relation][2]:

In mathematics (more specifically, in set theory and logic), a relation is a property that assigns truth values to combinations (k-tuples) of k individuals. Typically, the property describes a possible connection between the components of a k-tuple. For a given set of k-tuples, a truth value is assigned to each k-tuple according to whether the property does or does not hold. An example of a ternary relation (i.e., between three individuals) is: "X was-introduced-to Y by Z", where (X,Y,Z) is a 3-tuple of persons; for example, "Beatrice Wood was introduced to Henri-Pierre Roché by Marcel Duchamp" is true, while "Karl Marx was introduced to Friedrich Engels by Queen Victoria" is false.

维基百科说得很清楚:在SQL数据库管理系统中，这样的三元关系将是一个“表”，而不是一个“外键”(我冒昧地重命名了关系的“列”:X = who, Y = to, Z = by):

CREATE TABLE introduction (
  who INDIVIDUAL NOT NULL
, to INDIVIDUAL NOT NULL
, by INDIVIDUAL NOT NULL
, PRIMARY KEY (who, to, by)
);

此外，它将包含(可能在其他中)这个“row”:

INSERT INTO introduction (
  who
, to
, by
) VALUES (
  'Beatrice Wood'
, 'Henri-Pierre Roché'
, 'Marcel Duchamp'
);

但不是这个:

INSERT INTO introduction (
  who
, to
, by
) VALUES (
  'Karl Marx'
, 'Friedrich Engels'
, 'Queen Victoria'
);

关系数据库字典:

relation (mathematics) Given sets s1, s2, ..., sn, not necessarily distinct, r is a relation on those sets if and only if it's a set of n-tuples each of which has its first element from s1, its second element from s2, and so on. (Equivalently, r is a subset of the Cartesian product s1 x s2 x ... x sn.) Set si is the ith domain of r (i = 1, ..., n). Note: There are several important logical differences between relations in mathematics and their relational model counterparts. Here are some of them: Mathematical relations have a left-to-right ordering to their attributes. Actually, mathematical relations have, at best, only a very rudimentary concept of attributes anyway. Certainly their attributes aren't named, other than by their ordinal position. As a consequence, mathematical relations don't really have either a heading or a type in the relational model sense. Mathematical relations are usually either binary or, just occasionally, unary. By contrast, relations in the relational model are of degree n, where n can be any nonnegative integer. Relational operators such as JOIN, EXTEND, and the rest were first defined in the context of the relational model specifically; the mathematical theory of relations includes few such operators. And so on (the foregoing isn't meant to be an exhaustive list).

如果你是一个开发人员，你应该会写代码

去年我做了很多面试，在我的面试部分，我应该测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我一开始的问题是:

假设可以使用函数4 *(1 - 1/3 + 1/5 - 1/7 +…)来估计圆周率，使用更多的项来获得更高的精度，编写一个计算圆周率的函数，其精度为小数点后5位。

这是一个应该让你思考的问题，但对于一个经验丰富的开发人员来说不应该是遥不可及的(它可以用大约10行c#来回答)。然而，我们的许多候选人(应该是中介机构预先筛选的)甚至无法开始回答这个问题，甚至无法解释他们将如何回答这个问题。所以过了一段时间，我开始问一些更简单的问题，比如:

给定圆的面积是π乘以半径的平方，写一个函数来计算圆的面积。

令人惊讶的是，超过一半的候选人不能用任何语言编写这个函数(我可以阅读大多数流行的语言，所以我让他们使用他们选择的任何语言，包括伪代码)。我们有“c#开发人员”，他们不能用c#编写这个函数。

我对此感到很惊讶。我一直认为开发人员应该会写代码。现在看来，这似乎是一个有争议的观点。当然是在面试中!

编辑:

在评论中有很多关于第一个问题是好是坏的讨论，以及你是否应该在面试中问这么复杂的问题。我不打算在这里深入研究这个问题(这是一个全新的问题)，除了说你在很大程度上错过了文章的重点。

是的，我说过人们在这个问题上无法取得任何进展，但第二个问题很琐碎，许多人在这个问题上也无法取得任何进展!任何自称为开发人员的人都应该能够不假思索地在几秒钟内写出第二个问题的答案。很多人做不到。

微软Windows是软件开发的最佳平台。

推理: 微软用优秀而廉价的开发工具，平台和API都有良好的文档记录，平台正在快速发展，这为开发者创造了很多机会，操作系统拥有庞大的用户基础，这对于明显的商业原因很重要，有一个庞大的Windows开发者社区，我还没有因为选择微软而被解雇。

我不明白为什么人们认为Java绝对是大学里最好的“首选”编程语言。

首先，我认为第一种编程语言应该强调学习控制流和变量的必要性，而不是对象和语法

另一方面，我相信没有在C / c++中调试内存泄漏经验的人无法完全理解Java带来的好处。

同样，自然的进展应该是从“我怎么能做这个”到“我怎么能找到做那个的库”，而不是相反。

清理和重构在(团队)开发中非常重要

A lot of work in team development has to do with management. If you are using a bug tracker than it is only useful if someone takes the time to close/structure things and lower the amount of tickets. If you are using a source code management somebody needs to cleanup here and restructure the repository quite often. If you are programming than there should be people caring about refactoring of the lazy produced stuff of others. It is part of most of the aspects some will face while doing software development.

大家都同意这种管理的必要性。而且它总是被跳过的第一件事!