Is this technique a design pattern? If so, what's it called?

Question

I'll use C# as an example, but it should apply globally. Say I have a string value that should be one of a few constants, but I also want the client to set which string value to use so:

private int foo;
private string bar;

public int Foo {
    get { return foo; }
    set
    {
        foo = value;
        bar = getStringValueFromDatabase(value);
    }
}

public string Bar { get { return bar; } }

I use this technique quite a lot and want to know if it's considered as any formal concept.

Answer 1

It's perfectly valid OO technique, though I think it can be made a bit more efficient if the lazy-loading (which is what this effectively is) is deferred until the Bar value is actually needed.

private int foo;
private string bar;

public int Foo 
{
    get { return foo; }
    set
    {
        foo = value;
        bar = null;
    }
}

public string Bar
{ 
    get 
    { 
        if(bar == null) 
            bar = getStringValueFromDatabase(Foo);
        return bar; 
    } 
}

Edit: I think that's an improvement on the original code though as others have observed, even better would be to abstract the data access into a separate layer.

Answer 2

Well, it is similar in a way to Lazy Loading, but it's not exactly that. At first glance, it actually seems a tad dangerous, in that setting a property has side effects. I believe that's generally frowned upon, but this is hardly an egregious violation.

Answer 3

The concept that I think of is something similar to a database foreign key, an association between two entities where one entity refers to the other through a handle (the key). More generally, you can call it an indirect association.

There are two time dependent aspects to this:

1. Setting the handle, thus creating the association
2. Retrieving the associated entity through that handle

There're many ways to code this, with eager or lazy loading, by fetching the related entity every time it's requested, by using a proxy, with or without temporal coupling, and also whose responsibility it is to carry out the two aspects above (could be the referring entity or the client code), which could potentially turn it into a direct association from the referring entity to the referred-to entity (the indirection would only be know to the client code).

Answer 4

If possible, it's safer to pass foo in the constructor, and make it readonly/final. Then you've created an object with dependencies. when you call the Bar getter, then use the captured state to compute the value if you want to do it lazily.

Answer 5

Say I have a string value that should be one of a few constants, but I also want the client to set which string value to use so:

1. A constant that is changed? Eh?

2. What you're doing is changing a property which is backed by a data store. It's not a constant. It might be a configuration variable.

3. The Patterns name might be Facade or Decorator or somesuch similar. If my code works, and is maintainable, I don't bother myself with the pattern names.

My comment on your code is you should have another layer of indirection - a function that manages the data storage/restoration. That will abstract it away from the database call.