blocks|key|3085688|text|原因有很多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3085689|Law+of+Demeter给出了一个结构原因(请注意，您的C%2B%2B教授的代码仍然违反了这一点！)。在您的示例中，edge必须了解terminal和outgoing_edges。这使得它紧密耦合在一起。|offset|length|style|CODE|3085690|作为替代方案|3085691|class+Edge+{
+private:
+++Node*+terminal;
+public:
+++Edges*+outgoing_edges()+{
++++++return+terminal->outgoing_edges;
+++}
}|code-block|syntax|javascript|3085692|现在，您可以在一个地方更改outgoing_edges的实现，而不必到处更改。老实说，对于像图这样的数据结构(它是紧密耦合的，边和节点不能彼此逃脱)，我并不真的相信这一点。在我的书中，这将是过于抽象的。|3085693|还有空引用的问题，在表达式a->b->c中，如果b为空怎么办？|3085694|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Law_of_Demeter^0|0|1K|4|1S|8|21|E|0|E|0|0|0|0|D|E|0|D|7|O|1|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@$D|12|E|13|F|G]|$D|14|E|15|F|G]|$D|16|E|17|F|G]]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|H|3|I|5|6|7|1B|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1C|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1D|8|@$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1G|8|@$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

There's a number of reasons.

The <a href="https://en.wikipedia.org/wiki/Law_of_Demeter">Law of Demeter</a> gives a structural reason (note that your C++ professors code still violates this though!). In your example, <code>edge</code> has to know about <code>terminal</code> and <code>outgoing_edges</code>. That makes it tightly coupled.

As an alternative

<pre><code>class Edge {
 private:
 Node* terminal;
 public:
 Edges* outgoing_edges() {
 return terminal-&gt;outgoing_edges;
 }
}
</code></pre>

Now you can change the implementation of <code>outgoing_edges</code> in one place without changing everywhere. To be honest, I don't really buy this in the case of a data structure like a graph (it is tightly coupled, edges and nodes can't escape each other). This'd be over-abstraction in my book.

There's the null dereference problem too, in the expression <code>a-&gt;b-&gt;c</code>, what if <code>b</code> is null?

blocks|key|3085734|text|你应该问问你的教授，为什么他认为这是一种糟糕的风格。我不这么认为，但是我认为他在终端声明中省略const是一种糟糕的风格。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3085735|对于像这样的单个代码片段来说，它的风格可能还不错。但是，请考虑以下内容：|3085736|void+somefunc(Edge+*edge)
{
+++if+(edge->terminal->outgoing_edges.size()+>+5)
+++{
++++++++edge->terminal->outgoing_edges.rezize(10);
++++++++edge->terminal->counter+=+5;
+++}
+++%2B%2Bedge->terminal->another_value;
}|code-block|syntax|javascript|3085737|这开始变得笨拙起来--它很难读，也很难写(我在输入的时候犯了大约10个打字错误)。它需要对这两个类的运算符->进行大量计算。如果运算符是微不足道的，但如果运算符做了任何令人兴奋的事情，那么它最终将做大量的工作。|3085738|所以有两个可能的答案：|3085739|3085740|Maintanability|ordered-list-item|3085741|Efficiency|3085742|3085743|而像这样的单个代码片段，您无法避免额外的行。在上面这样的情况下，它将导致更少的输入。|3085744|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Z|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|10|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|13|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|14|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|16|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|W|$]]

You should ask your professor as to why he considers it bad style. I don't. I would however consider his omission of the const in the declaration of terminal to be bad style.

For a single snippet like that, it's probably not bad style. However consider this:

<pre><code>void somefunc(Edge *edge)
{
 if (edge-&gt;terminal-&gt;outgoing_edges.size() &gt; 5)
 {
 edge-&gt;terminal-&gt;outgoing_edges.rezize(10);
 edge-&gt;terminal-&gt;counter = 5;
 }
 ++edge-&gt;terminal-&gt;another_value;
}
</code></pre>

This is starting to get unwieldy - it is difficult to read, it is difficult to write (I made approximately 10 typos when typing that). And it requires a lot of evaluation of the operator-> on those 2 classes. OK if the operator is trivial, but if the operator does anything exciting, it's going to end up doing a lot of work.

So there's 2 possible answers:

<ol>
<li>Maintanability</li>
<li>Efficiency</li>
</ol>

And a single snippet like that, you can't avoid the extra line. In something like the above, it'd have resulted in less typing.

blocks|key|221748|text|您所展示的两个代码片段(当然)在语义上是相同的。当涉及到风格问题时，建议你简单地遵循你的教授的要求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|221749|比你的第二个代码片段稍好一点的是：|221750|Node*+terminal+=+(edge+?+edge->terminal+:+NULL);
return+(terminal+?+terminal->outgoing_edges[0]+:+NULL);|code-block|syntax|javascript|221751|我假设outgoing_edges是一个数组；如果不是，您还必须检查它是否为NULL或空。|221752|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The two code snippets you have shown is (of course) semantically identical. When it comes to matters of style, suggest you simply follow what your professor wants.

Slightly better than your second code snippet would be:

<pre><code>Node* terminal = (edge ? edge-&gt;terminal : NULL);
return (terminal ? terminal-&gt;outgoing_edges[0] : NULL);
</code></pre>

I am assuming that outgoing_edges is an array; if not, you have to check for that being NULL or empty as well.

blocks|key|223698|text|嗯，我不能肯定你的教授的意思，但我有一些想法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|223699|首先，像这样的代码可能是“不那么明显的”：|223700|someObjectPointer->foo()->bar()->foobar()|code-block|syntax|javascript|223701|你不能真正说出foo()的结果是什么，因此你也不能真正说出bar()被调用的是什么。这是同一个物体吗？或者它可能是一个正在创建的临时对象？或者可能是别的原因？|offset|length|style|CODE|223702|另一件事是如果你必须重复你的代码。考虑下面这样的例子：|223703|complexObject.somePart.someSubObject.sections[i].doSomething();
complexObject.somePart.someSubObject.sections[i].doSomethingElse();
complexObject.somePart.someSubObject.sections[i].doSomethingAgain();
complexObject.somePart.someSubObject.sections[i].andAgain();|223704|将其与以下内容进行比较：|223705|section+*+sectionPtr+=+complexObject.somePart.someSubObject.sections[i];
sectionPtr->doSomething();
sectionPtr->doSomethingElse();
sectionPtr->doSomethingAgain();
sectionPtr->andAgain();|223706|您可以看到第二个示例不仅更短，而且更容易阅读。|223707|有时函数链更简单，因为您不需要关心它们返回的内容：|223708|resultClass+res+=+foo()->bar()->foobar()|223709|vs|223710|classA+*+a+=+foo();
classB+*+b+=+a->bar();
classC+*+c+=+b->foobar();|223711|另一件事是调试。调试长的函数调用链是非常困难的，因为您根本不能理解它们中的哪一个会导致错误。在这种情况下，打破链条很有帮助，更不用说你还可以做一些额外的检查，比如|223712|classA+*+a+=+foo();
classB+*+b;
classC+*+c;
if(a)
+++b+=+a->bar();
if(b)
+++c+=+b->foobar();|223713|所以，总的来说，你不能说它是一种“坏”或“好”的风格。你必须先考虑你的情况。|223714|entityMap^0|0|0|0|7|5|T|5|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1F|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1G|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1H|8|@$K|1I|L|1J|M|N]|$K|1K|L|1L|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1N|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|F|7|1P|8|@]|9|@]|A|$G|H]]|$1|W|3|X|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1R|8|@]|9|@]|A|$]]|$1|10|3|11|5|F|7|1S|8|@]|9|@]|A|$G|H]]|$1|12|3|13|5|6|7|1T|8|@]|9|@]|A|$]]|$1|14|3|15|5|F|7|1U|8|@]|9|@]|A|$G|H]]|$1|16|3|17|5|6|7|1V|8|@]|9|@]|A|$]]|$1|18|3|19|5|F|7|1W|8|@]|9|@]|A|$G|H]]|$1|1A|3|1B|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]]|1D|$]]

Well, I can't be sure about what your professor did mean, bu I have some thoughts. 

First of all, code like this can be "not-so-obvious":

<pre><code>someObjectPointer-&gt;foo()-&gt;bar()-&gt;foobar()
</code></pre>

You can't realy say what is the result of <code>foo()</code>, and thus you can't really say on what is the <code>bar()</code> being called. Is that the same object? Or maybe its a temp object that is being created? Or maybe it's something else?

Another thing is if you have to repeat your code. Consider an example like this:

<pre><code>complexObject.somePart.someSubObject.sections[i].doSomething();
complexObject.somePart.someSubObject.sections[i].doSomethingElse();
complexObject.somePart.someSubObject.sections[i].doSomethingAgain();
complexObject.somePart.someSubObject.sections[i].andAgain();
</code></pre>

Compare it with such:

<pre><code>section * sectionPtr = complexObject.somePart.someSubObject.sections[i];
sectionPtr-&gt;doSomething();
sectionPtr-&gt;doSomethingElse();
sectionPtr-&gt;doSomethingAgain();
sectionPtr-&gt;andAgain();
</code></pre>

You can see how the second example is not only shorter, but easier to read. 

Sometimes the chain of functions is easier, because you don't need to bother with what they return:

<pre><code>resultClass res = foo()-&gt;bar()-&gt;foobar()
</code></pre>

vs

<pre><code>classA * a = foo();
classB * b = a-&gt;bar();
classC * c = b-&gt;foobar();
</code></pre>

Another thing is debugging. It is very hard to debug long chains of function calls, because you simply can't understand which of them causes the error. In this case, breaking the chain helps a lot, not to mention you can do some extra checks too, like

<pre><code>classA * a = foo();
classB * b;
classC * c;
if(a)
 b = a-&gt;bar();
if(b)
 c = b-&gt;foobar();
</code></pre>

So, to summarize, you can't say that it is a "bad" or "good" style in general. You have to consider your circumstances first.

blocks|key|3085799|text|在目前的形式下，两者都不一定更好。但是，如果您要在第二个示例中添加对null的检查，那么这将是有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3085800|if+(edge+!=+NULL)
{
+++Node*+terminal+=+edge->terminal;
+++if+(terminal+!=+NULL)+return+terminal->outgoing_edges[0];
}|code-block|syntax|javascript|3085801|尽管这仍然是不好的，因为谁能保证outgoing_edges被正确地填充或分配。一个更好的办法是调用一个名为outgoingEdges()的函数，它可以为您完成所有的错误检查，并且永远不会导致未定义的行为。|offset|length|style|CODE|BOLD|3085802|entityMap^0|0|0|G|E|1I|F|2O|6|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Q|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|R|8|@$I|S|J|T|K|L]|$I|U|J|V|K|L]|$I|W|J|X|K|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|O|$]]

Neither are necessarily better in their current form. However, if you were to add a check for null in your second example, then this would make sense.

<pre><code>if (edge != NULL)
{
 Node* terminal = edge-&gt;terminal;
 if (terminal != NULL) return terminal-&gt;outgoing_edges[0];
}
</code></pre>

Though even that is still bad because who is to say that <code>outgoing_edges</code> is properly populated or allocated. A better bet would be to call a function called <code>outgoingEdges()</code> that does all that nice error checking for you and never causes you undefined behavior.

Our C++ professor mentioned that using the result of operator-> as input into another operator-> is considered bad style.

So instead of writing:

<pre><code>return edge-&gt;terminal-&gt;outgoing_edges[0];
</code></pre>

He would prefer:

<pre><code>Node* terminal = edge-&gt;terminal;
return terminal-&gt;outgoing_edges[0];
</code></pre>

<ol>
<li>Why is this considered bad style?</li>
<li>How could I restructure my program to avoid the 'bad style' but also avoid the extra line of code that is created as per the above suggestion?</li>
</ol>

Why is foo->bar->foobar considered bad style? And how to avoid without adding code?

数据结构

我们的C++教授提到，使用operator->的结果作为另一个operator->的输入被认为是不好的风格。因此，与其写：return edge->terminal->outgoing_edges[0];他更喜欢：Node* terminal = edge->terminal;return terminal->outg...

问为什么foo->bar->foobar被认为是糟糕的风格？如何在不添加代码的情况下避免呢？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么foo->bar->foobar被认为是糟糕的风格？如何在不添加代码的情况下避免呢？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么foo->bar->foobar被认为是糟糕的风格？如何在不添加代码的情况下避免呢？
EN