Best practice for method chaining ("return this")

I have an abstract class called DatabaseRow that, after being derived and constructed, is mainly loaded from a Load(object id) method.

I have lots of code that creates a new instance of the class, loads it from an ID, then returns the class. I'd like to simplify开发者_如何学运维 this code into one line of code (just to be neat, there are plenty of classes that will just have lists of properties that return these Loaded instances).

There are two ways I can think of doing it, but neither seem 'right' to me.

1. I could return this; at the end of my Load method and use return new Derived().Load(id);

2. I could create a generic method to return a loaded method.

public static T LoadRow<T>(object id) where T : DatabaseRow, new()
{
    T row = new T();
    row.Load(id);
    return row;
}

I've seen some other code that uses the same method as number 1, but I've never seen any experienced developer recommend it, nor have I came across any methods in the .NET framework that do the same thing, so maybe this isn't best practice?

Does anybody know of any other solutions that could be better than both of these?

Solution:

After reading SirViver's answer and comment, I realised that all the properties being returned need to be cached anyway. The solution was sightly different, but similar to option 2 (that I wouldn't expect anyone to come up with this answer as I didn't explain this part of the design)

All these instances will be loaded from a value retrieved from another column in the database (database relationships if you like). Instead of trying to load the new instance from this value, I made a method to load the instance from the column name and cache the loaded value in a Dictionary. This works well as this is one of the primary functions of the DatabaseRow class.

    private Dictionary<string, DatabaseRow> linkedRows;

    protected T GetLinkedRow<T>(string key) where T : DatabaseRow, new()
    {
        if (linkedRows.ContainsKey(key)) return (T)linkedRows[key];
        else
        {
            T row = new T();
            row.Load(this[key]);
            linkedRows.Add(key, row);
            return row;
        }
    }

---

Personally, I think it's bad practice to chain method calls that have actual sideffects on the object instance. To be honest, I think both examples are quite ugly "hacks" whose only purpose is saving two lines of code. I don't think the result is actually more readable either.

If you want a record to be loaded immediately, I'd probably rather supply a constructor variant that takes the ID you load from and make the object auto-populate itself on construction, though when I think about it, I wouldn't bother at all to be honest - cramming more information in a single line does not make for more read- and maintainable code.

---

Number 1 is gaining in popularity in some circles; it's often called fluent programming when there's an interface that defines great numbers of these methods and long chains can be assembled. The key to doing this successfully is never to define a method that sometimes returns this, but other times returns null. If this is always returned (unless there's an exception) it's perfectly good style.

Personally I'm not as fond of solutions like number 2, as it could be said to violate the "one responsibility" principle.

---

Option 1 is only acceptable if it is possible to have a row without being loaded. This is due to the pattern allowing you to do this:

return new Derived();

Personally I would prefer the static method. But I suspect it is simply a matter of personal preference.

As ssg says the other option (lets call it option 3) is to overload the constructor in Derived which would also work, however having lots of constructors can often be confusing as the calling code does not have anything in it which describes what is going on.

Option 1:

return new Derived().Load(10);

Option 2:

return Derived.Load(10);

Option 3:

return new Derived(10);

Option 1 looks like you are getting a superfluous object created. Option 2 is good because it does what it looks like it is doing. Option 3 leaves confusion about what it does.

---

Although I personally like methods returning this as it allows them to be chained, I think in the .NET framework (up until Linq), this was frowned upon. The reason that pops to mind is this:

Methods either return a result or change the state of the object. Returning this is a bit of both: Changing the state of the object and then returning a "result" - except that result is the modified original object. This doesn't fit the expectations of the user.

What about:

public class Derived : DatabaseRow
{
    public Derived(object id):
    {
        Load(id);
    }
}

And use it like this:

return new Derived(id);