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

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

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

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


当前回答

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

... 那就是当我们(希望)得到它们的时候。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).

其他回答

我真的不喜欢当人们告诉我使用getter和setter而不是使变量公共时,你应该能够获得和设置类变量。

我完全同意如果是改变对象中的一个变量在你的对象中,你不会得到这样的东西:a.b.c.d.e = something;但我更愿意使用:a.x = something;然后a.setX(东西);我认为a.x =某物;实际上,在同一个例子中,它们都更容易阅读,而且比设置/获取更漂亮。

我不明白为什么要这样做:

void setX(T x) { 这个->x = x; }

T getX () { 返回x; }

这就需要更多的代码,需要更多的时间,你要一遍又一遍地做,这只会让代码更难阅读。

我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能,买更多的机器。

Java是我们这一代的COBOL语言。

每个人都要学会编码。在大公司中有运行它的代码,这些公司会试图让它运行几十年。与所有其他选择相比,每个人都开始鄙视它,但无论如何都被迫使用它,因为它可以支付账单。

硬编码很好!

真的,在许多情况下更有效,更容易维护!

我看到常数放入参数文件的次数真的非常频繁 你改变了水的冰点还是光速?

对于C程序,只需将这些类型的值硬编码到头文件中,对于java程序,只需将这些值硬编码到静态类中等等。

当这些参数对你的程序行为有巨大的影响时,你真的想对每一个变化做一个回归测试,这似乎是硬编码值更自然。当东西存储在参数/属性文件中时,人们很容易认为“这不是一个程序变更,所以我不需要测试它”。

另一个好处是,它可以防止人们在参数/属性文件中混淆重要值,因为根本没有任何重要值!

我通常持有相当有争议的、强烈的和响亮的观点,所以这里只是其中的一些:

“因为我们是微软的机构/合作伙伴/专家”从来都不是一个有效的论点。

我现在工作的公司首先把自己定位为微软专家。所以前面提到的论点被抛出了很多次,我还没有看到一个背景下它是有效的。

我不明白为什么要在每一个适用的角落推广微软的技术和产品,而不顾客户和员工的满意度,以及一般的实用主义。

这正是我对软件行业政治深恶痛绝的一个基石。

MOSS(微软Office Sharepoint服务器)就是一坨屎。

有点像第一个观点,但我真的认为MOSS应该被赶出市场。它需要花费大量的授权和设置费用,破坏了web标准,让开发者非常不开心。我还没有看到一个MOSS项目有一个总体积极的结果。

然而,一次又一次,客户找到我们并要求MOSS解决方案。