Why does the C# DataMember attribute allow serialization of private fields and properties?

Why does the C# DataMember attribute allow serialization of private fields and properties?

Isn't the principle of self-encapsulation much more fundamental than serialization?

Serialization happens using reflection so we can change your question:

Isn't the principle of self-encapsulation much more fundamental than reflection?

So here is answer

Is Reflection breaking the encapsulation principle?

问题

Okay, let's say we have a class defined like

public class TestClass
{
    private string MyPrivateProperty { get; set; }

    // This is for testing purposes
    public string GetMyProperty()
    {
        return MyPrivateProperty;
    }
}

then we try:

TestClass t = new TestClass { MyPrivateProperty = "test" };

Compilation fails with TestClass.MyPrivateProperty is inaccessible due to its protection level, as expected.

Try

TestClass t = new TestClass();
t.MyPrivateProperty = "test";

and compilation fails again, with the same message.

All good until now, we were expecting this.

But then one write:

PropertyInfo aProp = t.GetType().GetProperty(
        "MyPrivateProperty",
        BindingFlags.NonPublic | BindingFlags.Instance);

// This works:
aProp.SetValue(t, "test", null);

// Check
Console.WriteLine(t.GetMyProperty());

and here we are, we managed to change a private field.

Isn't it abnormal to be able to alter some object's internal state just by using reflection?

Edit:

Thanks for the replies so far. For those saying "you don't have to use it": what about a class designer, it looks like he can't assume internal state safety anymore?

回答1

Reflection breaks encapsulation principles by giving access to private fields and methods, but it's not the first or only way in which encapsulation can be circumvented; one could argue that serialization exposes all the internal data of a class, information which would normally be private.

It's important to understand that encapsulation is only a technique, one that makes designing behaviour easier, provided consumers agree use an API you have defined. If somebody chooses to circumvent your API using reflection or any other technique, they no longer have the assurance that your object will behave as you designed it. If somebody assigns a value of null to a private field, they'd better be ready to catch a NullReferenceException the next time they try to use your class!

In my experience, programming is all about assertions and assumptions. The language asserts constraints (classes, interfaces, enumerations) which make creating isolated behaviour much easier to produce, on the assumption that a consumer agrees to not violate those boundaries.

This is a fair assertion to make given it makes a divide-and-conquer approach to software development more easy than any technique before it.

回答2

Reflection is a tool. You may use it to break encapsulation, when it gives you more than it takes away.

Reflection has a certain "pain" (or cost -- in performance, in readability, in reliability of code) associated with it, so you won't use it for a common problem. It's just easier to follow object-oriented principles for common problems, which is one of the goals of the language, commonly referred to as the pit of success.

On the other hand, there are some tasks that wouldn't be solvable without that mechanism, e.g. working with run-time generate types (though, it is going to be much-much easier starting from .NET 4.0 with it's DLR and the "dynamic" variables in C# 4.0).