Attributes vs. Single Responsibility Principle

• Download source code - 31.7 KB

Background 

Attributes are a great resource that allows developers to put extra information on types and members.  

They are great in the sense that we put all we need together and they are completely refactoring friendly, as when a member is renamed all its attributes stay there. But sometimes (or should I say many times) that initial benefit ends up causing more trouble than they really solve.

Single Responsibility Principle

In Wikipedia I found this definition:

In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Even if the idea is great, it does not really tell me when a class (or better, a type as we have structs too) has a single responsibility or not.

Let's see the int (System.Int32) type.

An int variable is a simple value holder. But the struct has methods to parse a string and return an int, to convert that int to a string, to compare an int with another, to do math operations, and so on. It is OK to me, but I can already say that it is a little counter intuitive that some math operations are in the int type itself while others are in the Math class. Shouldn't methods like Math.Max be in the original types (int.Max, double.Max, and so on)?

Well, maybe, but this article is not really to discuss that point. The point I want to discuss are attributes and how they violate the Single Responsibility Principle.

So, let's see some attribute usages:

[Serializable]
[DisplayName("Non-Empty String")]
[Description("This struct simple holds a string value, which must be null or have a non-empty content.")]
public struct NonEmptyString
{
  public NonEmptyString(string value)
  {
    if (value.Length == 0)
      throw new ArgumentException("value must be null or should have a non-empty content.", "value");

    _value = value;
  }

  private readonly string _value;
  [Description("This property should be null or have a non-empty content.")]
  public string Value
  {
    get
    {
      return _value;
    }
  }
}

The struct was created with a single responsibility in mind (store a non-empty string). You may not like the idea of creating a struct for such a simple validation, but that's not the point here. The point is its responsibility that was altered to:

• Make it [Serializable], so it can be used in ASP.NET external sessions (or serialized for any other reason);
• Put a better name and description, in case it is used by some kind of editor.

See the problem?

If not, I will tell you. The type should not be worried about the text description to be used by a possible editor. It should not care about a Serializable attribute. It is the responsibility of a serializer to know if it is serializable or not. It is the responsibility of an editor to know some way of finding a better name and description.

Also, I can say that there are other problems, like, how do we support non-English descriptions with this model?

To make the code conform to the Single Responsibility Principle, it should look like this:

public struct NonEmptyString
{
  public NonEmptyString(string value)
  {
    if (value.Length == 0)
      throw new ArgumentException("value must be null or should have a non-empty content.", "value");

    _value = value;
  }

  private readonly string _value;
  public string Value
  {
    get
    {
      return _value;
    }
  }
}

That's OK from the Single Responsibility Principle idea. But then how do we solve the [Serializable] thing? How can an editor find the right DisplayName and Description?

Well... that can be a little tricky with the old code. Surely we can create yet another type, like SerializableNonEmptyString that holds a NonEmptyString and adds serialization support. But if we want to serialize an object that already holds a NonEmptyString we will end-up needing to copy the object to a similar one with serializable types. So, for those cases, maybe it is better to violate the Single Responsibility Principle. Or if we have the option, we can recreate the serialization process (or use an alternative one) that allows us to add specific serialization code for already existing types.

Effectively, the idea is: Every type will have a single responsibility. So the NonEmptyString has the single responsibility of holding a string that is either null or non-empty. Then, a serializer type will know how to serialize a NonEmptyString. It is enough to inform a serialization mechanism that we have the serializer for such a type.

In fact, with this model, any type that already exists on a third-party DLL can be serialized if it is possible to access all needed properties to store them and reconstruct (or find) the instance later. So, the data type can exist in an assembly and the serializer for it can exist in another assembly. I can say that I use that to serialize WPF colors, for example.

What about the DisplayName and Description?

Well... I can say that a Dictionary<MemberInfo, string> will do the job. Surely there should be some code available to load descriptions for MemberInfos, but with such a dictionary we can already bind a DisplayName or Description to any existing member (in fact, or we will have two different classes with a similar structure, or we should create another type to store the DisplayName and the Description together).

The best thing with this approach is that we can, again, do it in different assemblies. So, if we are dealing with 3rd party classes, we can still add a display name or a description to the types found there. With a little more work we can support different languages, and everything without changing the original types.

Sample Code

The sample code in this article is a small Binary Serialization library that works using the Single Responsibility Principle. ConfigurableBinarySerializer must be configured (that is, the serializer for each item type must be added by the user). Also, there is a very small sample with it that only shows how to register the serializers, how to serialize and deserialize. If everything works OK, the data is serialized to and deserialized from a memory stream, and the console application finishes. So, only use it to see the code.

I don't expect that people simple use this serializer as a replacement for normal serialization techniques, but I hope it gives a better understanding on the Single Responsibility Principle. 

One way versus the way

I already received two messages from people that say that attributes don't violate the Single Responsibility Principle. They in fact have valid points. But let's look from an outside view.

Someone (a user, a chef, another programmer) asks for a component that:

• Has two properties.
• Has two more properties that are calculated from the first ones (P1+P2 and P1*P2).

The programmer easily does something like this:

public class SomeClass
{
  public int P1 { get; set; }
  public int P2 { get; set; }

  public int Sum
  {
    get
    {
      return P1 + P2;
    }
  }
  public int Multiplication
  {
    get
    {
      return P1 * P2;
    }
  }
}

In fact, the code works. But then the developer receives a "warning" that his code is not right. The fact is:

• He must put the [Serializable] attribute in his class, or else it will not work
• He must put a Description on the calculated properties.

But to him, that was not what was asked. You may consider him lazy, but he did what he was asked to do.

Is he really wrong?

My answer is no. Not because someone forgot to say that the class was serializable, but because the purpose of the class is to store data. Being serializable is another "trait" of such a class... but it is better to put that trait somewhere else and let the one responsible for seeing what's serializable to say: Hey, that's a class that can be serialized without problems!

Don't put the need on the programmer that did the class. And, consequently, don't put that need in the class itself. If someone else, at a later time, can figure out that it's possible, allow that. That means: Allow that to be put at run-time, instead of only allowing that at compile-time. And that's where the real question is:

Are you using attributes as hints or are you using it as needs? As hints, that may be a small violation. But as needs, that's a problem.