Does C# 6.0's new null-conditional operator go against the Law of Demeter?

Question

The Law of Demeter states the following:

• Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.
• Each unit should only talk to its friends; don't talk to strangers.
• Only talk to your immediate friends.

C# 6.0 introduced a new operator called the null-conditional operator. IMHO, it makes coding easier and improves readability. But it also makes it easier to write more coupled code, as it is easier to navigate through class fields, already checking for nullity (something like var x = A?.B?.C?.D?.E?.F?).

Is it correct to state that this new operator goes against the Law of Demeter?

Answer 1

Is it correct to state that this new operator goes against the Law of Demeter?

No^*

---

^* The null conditional operator is a tool within the language and the .NET framework. Any tool has the ability to be abused and used in ways that could harm the maintainability of a given application.

But the fact that a tool can be abused doesn't necessarily mean that it has to be abused, nor that the tool violates any particular principle(s) that may be held.

The Law of Demeter and others are guidelines about how you should write your code. It's targeted to humans, not the tools. So the fact that the C# 6.0 language has a new tool within it doesn't necessarily affect how you should be writing and structuring your code.

With any new tool, you need to evaluate it as ... if the guy who ends up maintaining your code will be a violent psychopath .... Note again, that this is guidance to the person writing the code and not about the tools being used.

Answer 2

Sort of.

If you're only doing one access (a?.Foo) then it is equivalent to:

a == null ? null : a.Foo

which most people would agree is not a violation of the Law of Demeter. At that point, it is just syntactic sugar to improve readability.

Anything more than that, and it probably would violate the Law of Demeter, and this feature does tend to promote that sort of usage. I would even say that the above "good" usage alone isn't enough to warrant this sort of change to the language, so I expect that it was made to support the less clearly good usage.

That said, it is worth remembering that the Law of Demeter isn't a law per se, but more of a guideline. Lots of code violates it and works well. Sometimes the simplicity of design or of code is worth more than the risk posed by violating the Law of Demeter.

Answer 3

No. Let's consider both the operator on its own, and the heavily chained use you have for it.

On its own .?A depends upon the same amount of knowledge of the class the left-value is and of the type returned by the method as .A != null does, viz. It needs to know about that the A property exists and returns a value that can be compared with null.

We can only argue that this violates the law of Demeter if typed properties do. We aren't even forced to have A as a concrete type (its value could be of a derived type). The coupling here is minimal.

Now lets consider var x = A?.B?.C?.D?.E?.F.

Which means that A must be of a type that could be null, or could have a B property, which must be of a type that could be null or have a C property, and so on until the type of the E property being something that could be null or could have an F property.

In other words, we need to be doing this with either a statically-typed language or have applied a constraint on the types that can be returned if the typing is loose. C# in most cases uses static typing, so we've changed nothing.

If we had then the following code would also violate the law:

ExplicitType x;
var b = A.B;
if (b == null)
  x = null;
else
{
  var c = b.C;
  if (c == null)
    x = null;
  else
  {
    var d = c.D;
    if (d == null)
      x = null;
    else
    {
      var e = d.E;
      if (e == null)
        x = null;
      else
        x = e.F;
    }
  }
}

Which is exactly the same. This code that is using the coupling of different elements needs to "know" about the full chain of coupling, but it is using code that doesn't violate the Law of Demeter to do so, with each unit having a well-defined coupling with the next.

Answer 4

Object may be created for the purpose of encapsulating behaviors or holding data, and objects may be created for the purpose of being shared with outside code or held privately by their creator.

Objects which are created for the purpose of encapsulating behavior (whether shared or not), or for the being shared with outside code (whether they encapsulate behavior or data) should generally be accessed through their surface interface. When data-holding objects are created for use exclusively by their creator, however, the normal Law-of-Demeter reasons for avoiding "deep" access don't apply. If part of a class which stores or manipulate data in the object is changed in a way that would require adjusting other code, it will be possible to guarantee that all such code gets updated because--as noted above--the object was created for the exclusive use of one class.

While I think the ?. operator could perhaps have been better designed, there are enough situations where objects make use of nested data structures that the operator has many use cases which would not violate the principles expressed by the Law of Demeter. The fact that it could be used to violate the LoD should not be taken as an argument against the operator, since it is no worse than the "." operator in that regard.