I'm writing a conversion mechanism in C#. I deserialize a big XML document of one type and return a big XML document of another type (via serialization of another object).

While I'm doing the conversion, I find myself doing a TON of null checks (checking whether or not a certain property has a value, which then would need to be translated). Here's an example piece of code:

You'll be glad to know that C# 6 will address this with the Null Propagation ?. operator. You'll be able to do this: Console.WriteLine( MyPatientCareReport?.eHistory?.eHistoryCurrentMedsGroup?[0]?.eHistory12 ).
–
dcastroAug 12 '14 at 18:58

@dcastro's comment is exactly what I was looking for... a way to access inner elements of an object without null-checking every step of the way. Now that I know this is not possible (yet), maybe we can find another way to do this.
–
MattAug 12 '14 at 20:33

If any of these implementation details were to change, you would end up rewriting a lot of code.

In object-oriented programming, encapsulation is the term for not
only grouping data and behavior, but also hiding data and behavior
implementation details within a class ... so that the inner workings
of a class are not exposed. This reduces the chances that callers will
modify the data inappropriately or program according to the
implementation, only to have it change in the future. -- Essential C#
5.0

Code that violates the Law of Demeter is a candidate for Hide
Delegate, e.g. manager = john.getDepartment().getManager() can be
refactored to manager = john.getManager(), where the Employee class
gets a new getManager() method. However, not all such refactorings
make as much sense. Consider, for example, someone who’s trying to
kiss up to his boss: sendFlowers(john.getManager().getSpouse()).
Applying Hide Delegate here would yield a getManagersSpouse() method
in Employee. Yuck.

Now it's hard to suggest what this could look like because I'm not familiar with the problem domain, and a lot of the names here are meaningless to me (eHistory12? is there an eHistory13?). But you would probably want the code to end up looking something like this:

Not only it's not very object oriented, but such chaining can quickly become unreadable and difficult to maintain. Even if we suppose that your naming conventions are clear in your particular domain-specific case (and any other developer working on this project would know perfectly well what PN stands for or what 8801023 is), the:

A.eHistory.B[0].eHistory12.C

alone looks very strange: why is history inside a history? Why history 12? Why e? Why an array?

The array alone looks too weird. What is 0? A magic value? Doesn't your array hide a data structure, and if it does, why aren't you using a more clear representation of the data?

If you start moving the methods to where they belong, you'll end up removing those complicated chains and ambiguous types. Refactored code would finally look similar to: