Question

I’m refactoring a little bit of C# data access code from a previous developer and am curious about a pattern he used.

The code initially exposed collections (arrays) of a variety of ActiveRecord-style business objects – essentially objects wrapping database fields. I’m changing the arrays to generic lists, but the aspect of the code I’m curious about is that the previous developer had Get methods for each type of object he was wrapping, thusly:

public Thing GetThing(int i) {
    return things[i];
}

There are several of these methods, and I cannot for the life of me think of any possible advantage of using that mechanism over simply referring to things[i] directly. Let’s assume, for argument’s sake, that things is a public property, not a public field (in this case it’s actually an auto-implemented property, so that assumption is actually true).

Am I missing something obvious? Or even something esoteric?

UPDATE
I should probably clarify that these collections are currently accessed from within for loops:

for (int i = 0; i < thingsCount; i== ) {
    dosomthing( GetThing(i) );
    dosomethingelse( GetThing(i) );
}

which I am refactoring to:

for (int i = 0; i < thingsCount; i== ) {
    Thing thing = things[i];
    dosomthing( thing );
    dosomethingelse( thing );
}

and perhaps even to use things.foreach().

Answer 1

I don’t know if it’s obvious, but I do think you’re missing something.

Let’s say things is an IList<Thing>. Then exposing it directly (as Things) would allow calling code to call Add, Insert, RemoveAt, etc. Maybe the previous developer didn’t want to allow this (and I’m sure there are plenty of good reasons for that).

Even supposing it’s a Thing[] (so Add, etc. wouldn’t be available), exposing it as such would still allow calling code to do something like obj.Things[0] = new Thing(); which may be an operation that should not be allowed depending on the class’s implementation.

You could expose Things as a ReadOnlyCollection<Thing> which would take care of most of these problems. But what it comes down to is this: if the developer only wants to allow calling code to access items by index — nothing more — then providing a single GetThing method as the means to do so, honestly, makes by far the most sense.

Now, granted, there’s also this option: implementing a this[int] property with only a get accessor. But that only makes sense if the class in question is essentially a collection of Thing objects exclusively (i.e., there isn’t also a collection of some other type of object you want to provide access to within the class).

All told, I think the GetThing approach is pretty sound.

That said, from the way you’ve worded your question, it does sound like the previous developer made some other pretty poor decisions:

1. If he/she also exposed the things collection directly as a public property, well, then… that defeats the whole purpose of the GetThing method, doesn’t it? The result is simply a bloated interface (I generally think it’s not a great sign when you’ve got multiple methods to accomplish exactly the same thing, unless they’re clearly documented as aliases for some justifiable reason). [Update: It appears the previous developer did not do this. Good.]
2. It looks like the previous developer was also internally accessing items from things using the GetThing method, which is just silly (in my opinion). Why introduce the pointless overhead of extra method calls using a class’s public interface from within the class itself? If you’re in the class, you’re already inside the implementation and can access private/protected data all you want — no need to pretend otherwise.