0

First of all, sorry if this post is too long. I'll start with the…

Short version:

Is it generally advisable or a good idea to design an interface property as asynchronous simply because we cannot be sure whether each and every implementation can guarantee that it's evaluation will be cheap? That is, can it be a good idea to design an interface like this:

interface IFoo
{
    Task<IEnumerable<Bar>> BarsAsync { get; }
}

instead of like this:

interface IFoo
{
    IEnumerable<Bar> Bars { get; }
}

Long version:

Now let me explain how I arrived at this design question.

Let's start with the non-asynchronous version of the interface (shown right above).

Microsoft's framework design guidelines demand that getting the value of a property be cheap; but when we program against an interface, instead of against a particular implementation of IFoo, we cannot be certain that each and every implementation of IFoo that we might be using can and will adhere to that guideline.

What each and every implementation could do is to ensure "amortized cheapness", i.e. cache the property's value upon its first computation, so that at least subsequent accesses will be cheap. Eric Lippert writes in his blog article "When should I write a property?":

A common pattern is for a property to be a cache of an expensive, lazily-computed value […]. Though the property is expensive on its first access, every subsequent access is cheap, so the property is cheap in an amortized sense.

He goes on to suggest using Lazy<T> as an implementation detail towards that end, so let's look at a possible implementation of the above interface where evaluating Bars for the first time would be expensive, but not on subsequent calls:

internal class ExpensiveFoo : IFoo
{
    private readonly Lazy<IEnumerable<Bar>> bars;
    public IEnumerable<Bar> Bars { get { return bars.Value; } }
    public ExpensiveFoo() { bars = new Lazy<IEnumerable<Bar>>(GetBars); }
    private IEnumerable<Bar> GetBars() { … /* some expensive computation */ }
}

What I am wondering at this point is, wouldn't it be better to simply leak the possibility of an expensive first-time evaluation into the interface and change it to:

interface IFoo
{
    Task<IEnumerable<Bar>> BarsAsync { get; }
}

This would allow you to write both "always cheap" implementations as well as "amortized-cheap" implementations (like the above), with the consumer being aware of that fact.

internal class ExpensiveFoo : IFoo
{
    private Lazy<Task<IEnumerable<Bar>>> bars;
    public Task<IEnumerable<Bar>> BarsAsync { get { return bars.Value; } }
    public ExpensiveFoo() { bars = new Lazy<Task<IEnumerable<Bar>>>(GetBarsAsync); }
    private async Task<IEnumerable<Bar>> GetBarsAsync() { … };
}

internal class CheapFoo : IFoo
{
    public Task<IEnumerable<Bar>> BarsAsync { get { return Task.FromResult(bars) } }
    private IEnumerable<Bar> bars;
    public CheapFoo(IEnumerable<Bar> bars) { this.bars = bars; }
}

No matter which implementation gets used, one could then write code that potentially doesn't block even on the first property access:

Foo foo = …;
foreach (Bar bar in await foo.BarsAsync) …

Is this ever a good idea?

  • PS: I am of course aware of the possibility of simply not making Bars a property, but a method GetBars(). But I am trying to follow other design advice by Microsoft and Eric Lippert here: "First and foremost, the thing in question should logically be a property of the thing being modeled" – stakx Nov 23 '14 at 13:00
  • I think that quote says that when you write something as a property, then it should be a logical property of the object. It doesn't say it the other way around: that if something is a logical property, then you should write it as a property. I think that a GetBarsAsync() method is the right solution here. – svick Nov 23 '14 at 14:10
  • Use a method, an async property would be very stange, and what if it was something I wanted to databind against? – Andy Nov 23 '14 at 17:47
  • @Andy: Let's assume that I want to model Bars as a property because that is how it conceptually relates to a Foo - a property of it. See my above comment. (Besides, if you really wanted to databind against it – and that's a scenario that wasn't meant to be of foremost importance in my question –, then a method definitely wouldn't help any more than an async property.) – stakx Nov 23 '14 at 18:09
  • 2
    One of the reasons properties should never be "fancy" in terms of implementation, is they typically contain code that is executed in the debugger, in the watch windows and other places where variables can be viewed, such as tool tips. Methods are only executed on demand. – Frank Hileman Nov 27 '14 at 2:11
2

One of the reasons properties should never be "fancy" in terms of implementation, is they typically contain code that is executed in the debugger, in the watch windows and other places where variables can be viewed, such as tool tips. Methods are only executed on demand.

Some types of "fancy" properties:

  • Those that allocate memory when computing their value.
  • Those that do not return in constant time.
  • Those that return in constant time, but it is a "long" time (greater than a few milliseconds)
  • Those that have side effects: some argue this can be ok if the side effect is to initialize a field lazily. But even this can cause different behavior when attaching a debugger.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.