Auto-implemented properties with non null guard clause?

Question

I do agree with Mark Seeman's notion that Automatic Properties are somewhat evil as they break encapsulation. However I do like the concise syntax, readability and convenience they bring.

I quote:

public string Name { get; set; }

The problem with the code snippet isn’t that it contains too much ceremony. The problem is that it breaks encapsulation. In fact

“[…] getters and setters do not achieve encapsulation or information hiding: they are a language-legitimized way to violate them.”

James O. Coplien & Gertrud Bjørnvig. Lean Architecture. Wiley. 2010. p. 134.

Most of the time, adding a non-null guard clause is good enough for a property setter and I would like to know if there is a better way of doing it than one of the below. By better, I mean in a more concise/less repetitive way.

Using Code Contracts:

private string _username;
public virtual string Username
{
    get { return _username; }
    set 
    {  
        Contract.Requires(value != null);
        _username = value; 
    }
}

Using vanilla .NET:

private string _username;
public virtual string Username
{
    get { return _username; }
    set 
    {
        if (value == null) throw new ArgumentNullException("Username");
        _username = value; 
    }
}

don't think it's possible, honestly. But curiose to listen someone else. — Tigran, Jul 21 '11 at 08:30

score 7 · Accepted Answer · answered Jul 21 '11 at 21:29

7

I'll just quote the Code Contracts manual, § 2.3.1:

public int MyProperty { get; private set ; }

[ContractInvariantMethod]
private void ObjectInvariant () 
{
      Contract. Invariant ( this.MyProperty >= 0 );
      ...
}

answered Jul 21 '11 at 21:29

Henk Holterman

236,989
28
287
464

This seems to be the closest to what I am looking for, even though less than optimal as it will be run on every single getter/setter.. – Can Gencer Jul 28 '11 at 16:17

score 3 · Answer 2 · edited May 23 '17 at 12:07

3

You could use aspects from PostSharp to decorate the property setter with a null check:

http://www.sharpcrafters.com/blog/post/5-Ways-That-Postsharp-Can-SOLIDify-Your-Code-Lazy-Loading-of-Dependencies.aspx

How to create an aspect checking for null references on all methods in a class in postsharp

http://magpie.sytes.net/jesperhogstrom/2010/11/compiler-safe-null-checking-of-arguments-with-aspects/

edited May 23 '17 at 12:07

Community

1
1

answered Jul 21 '11 at 08:29

Adam Houldsworth

60,104
9
137
177

I was sensing that PostSharp would come up. I wonder how much performance hit you would get doing the same with Castle Interceptors and a custom attribute. – Can Gencer Jul 21 '11 at 08:34

score 0 · Answer 3 · answered Jul 21 '11 at 08:33

0

I would assume properties are just memory buffer from user point of view. only when a method (action) is invoke in user code, then checks on validity of the properties buffer should be checked (e.g., null checks throws exception).

your properties setter should place an invalid value to the internal member if data assigned is not valid (in your algorithm design). the error check and return should come from the method using this property value

answered Jul 21 '11 at 08:33

NirMH

4,247
2
36
59

I agree with this, I tend not to validate on entry to a property - but validate when that property is used. – Adam Houldsworth Jul 21 '11 at 08:34
3

I see your point, but I don't really agree with this, as it's against the "fail fast" principle which I am a believer of. – Can Gencer Jul 21 '11 at 08:36
@Can I tend to disregard that for anything that isn't UI stuff. Especially with property-based classes, such as with Xaml things. Property validity could relate to the content of another property, which could be as yet un-set. – Adam Houldsworth Jul 21 '11 at 08:38
@Adam, I think for DTOs this is ok, but for domain objects encapsulation and validation of state are very important. – Can Gencer Jul 21 '11 at 11:31
@Can I didn't say they weren't. Not validating on set into a property doesn't break that, so long as it's done later. – Adam Houldsworth Jul 21 '11 at 11:32
@Can, your approach, from my point, is strictly dictated by your program design, I mean, what properties are used for. In my design style, properties are replacing method parameters and it allows me to put more logic into the parameter "transfer" mechanism, e.g., parse a string. setting the value should never fail. but i do see your point as well, just i have no experience and never used this approach – NirMH Jul 21 '11 at 18:22

Auto-implemented properties with non null guard clause?

3 Answers3