Law of Reversibility of Attributes

I’ve come up with a simple law called Law of Reversability of Attributes.  It’s based on the physics law of a similar name.  Basically what the law means is that the inverse of a transformation should result in a return to the original state.

The Law of Reversibility of Attributes is defined as:

For a given state of an object; when a attribute’s value is changed, the inverse of that value, when applied to that attribute, will result in the object returning to its original state.

I say “attribute” rather than “property” to encompass methods that imply setting of attributes.  So, for example

            myObject.BooleanValue = !myObject.BooleanValue;
            myObject.BooleanValue = !myObject.BooleanValue;



means myObject will be in the same state after the second line of code than it was before the first line of code.

[UPDATE: interestingly, after I wrote this post–which was delay-published–Bill Wagner wrote a great article on a very similar topic in Visual Studio Magazine]

DotNetKicks Image

7 thoughts on “Law of Reversibility of Attributes”

  1. @Felipe: “Attributes” can be implemented as properties or methods. I’ve simply shown two ways of changing a property then changing it back–which should result in the same state as when started.

  2. @Patrick: Agreed. Immutability should be preferred (different law 🙂 When dealing with types that can’t be immutable, or don’t make sense being immutable I think it’s important that modifications be reversible.

  3. I have got what you tried to explain but can you give some other example which doesn’t have bool type attribute in the class. Just to make the understanding of the concept more clear.

  4. Sorry, bool was easy.

    How about:

    int oldWidth = rectangularShape.Width;
    rectangularShape.Width = 10;
    rectangularShape.Width = oldWidth;

    After this code executes all attributes of rectangularShape should be the same as they were before they executed.

  5. Agreed. Property setters that have side effects can lead to subtle bugs. For a case where that’s desired, I prefer a SetFoo() method to announce that the method’s doing more than just flipping bits.

Leave a Reply

Your email address will not be published. Required fields are marked *