When an instance of a class is returned, do all properties get returned?

Question

Let's say I have a class called Customer with some properties:

public class Customer
{
    public string CustAddr = GetCustAddr(); //Long procedure returning address

    public double CustAcct = GetCustAcct(); //Long procedure returning account

    public string CustInvoice = GetCustInvoice(); //Long procedure returning invoice
}

This class is returned via a function:

public Customer GetData(string query)
{
    Customer cust = new Customer();
    //set the values for each of the properties
    return cust;
}

Right now it is returning the whole class and I can use it like this:

lblDisplay = GetData("QUERY").CustAddr.ToString();

However, suppose each property takes a lot of time to compute. If I only want the CustAddr value, it still computes and has CustAcct and CustInvoice available for me.

How do I alter my function to only return the property I'm looking for, aside from breaking up my class into individual procedures to call? For example, I could just:

lblDisplay = GetCustAddr().ToString();

but that's not what I'm looking for. I think it's better to have all my data in an organized structure instead of a bunch of different procedures.

I suggest reading [What is the difference between a Field and a Property in C#?](http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c). — Jesse Good, Sep 29 '14 at 21:23

cdhowie · Accepted Answer · 2014-09-29T21:29:38.907

5

This is a great candidate for lazy initialization. Here I present an example using properties (you have fields).

public class Customer
{
    public Lazy<string> CustAddr { get; private set; }
    public Lazy<double> CustAcct { get; private set; }
    public Lazy<string> CustInvoice { get; private set; }

    public Customer()
    {
        CustAddr = new Lazy<string>(GetCustAddr);
        CustAcct = new Lazy<double>(GetCustAcct);
        CustInvoice = new Lazy<string>(GetCustInvoice);
    }
}

However, I would be remiss if I didn't point out that you should not use floating-point types (float, double) to store monetary values. Consider instead using decimal.

edited Sep 29 '14 at 21:29

answered Sep 29 '14 at 21:24

cdhowie

158,093
24
286
300

You point out using `double` instead of `decimal` but you don't bring up the fact that he is exposing public fields not properties? – Scott Chamberlain Sep 29 '14 at 21:26
3

That said, it's not clear why OP doesn't store the object in a variable and access each property one at a time instead of always creating it via `GetData`. – Tim Schmelter Sep 29 '14 at 21:27
1

@ScottChamberlain I am editing to use properties as well. But if I had to pick one of those two to fix, I would indeed pick usage of floating-point types. Properties begets easier maintenance; fixed-point for monetary data begets *not making bad calculations*. – cdhowie Sep 29 '14 at 21:27
1

One might want to hide the `Lazy` from the consumer and just expose the wrapped object via a property. Otherwise, you're leaking implementation details. – Nicholas Carey Sep 29 '14 at 21:42
@NicholasCarey I thought about doing that as well, but decided against it at least for this particular example. I have heard arguments for and against doing that, so I will let OP choose which approach makes the most sense for this situation. – cdhowie Sep 29 '14 at 21:53

BanksySan · Answer 2 · 2014-09-29T21:33:23.980

Why use an exotic solution when there's a vanilla one?

Implementing the calculation on the get of the properties.

NB: What you have are public fields, not properties

Very simple solution (nothing exotic!)

See this fiddle

e.g.

public class Customer
{
    private double ? _custAcct = null;
    public double CustAcct
    {
        get
        {
            if (!_custAcct.HasValue)
            {
                _custAcct = GetCustAcct();
            }

            return _custAcct.Value;
        }
    }

    private double GetCustAcct()
    {
        // do something that takes a long time
        return 1234.45;
    }
}

score 1 · Answer 3 · answered Sep 29 '14 at 21:28

What you're talking about is lazy loading or lazy initialization. You write your properties something like this:

public class MyLazyWidget
{
  . . .
  public BigExpensiveObject MyLazyProperty
  {
    get
    {
      if ( BigExpensiveObjectBackingStore == null )
      {
        BigExpensiveObjectBackingStore = ExpensiveOperation() ;
      }
        return BigExpensiveObjectBackingStore ;
    }
  }
  private static BigExpensiveObjectBackingStore = null ;
  . . .
}

And if your app is multi-threaded, you'll need to worry about race conditions, so you need to synchronize access to the static backing store:

public class MyLazyWidget
{
  . . .
  public BigExpensiveObject MyLazyProperty
  {
    get
    {
      lock( MyLazyPropertyLatch )
      {
        if ( BigExpensiveObjectBackingStore == null )
        {
          BigExpensiveObjectBackingStore = ExpensiveOperation() ;
        }
      }
      return BigExpensiveObjectBackingStore ;
    }
  }
  private static readonly object MyLazyPropertyLatch = new object() ;
  private static BigExpensiveObjectBackingStore = null ;
  . . .
}

Yes...but not everybody is using .Net 4.x. `Lazy` is a little more concise as well. — Nicholas Carey, Sep 29 '14 at 21:40

When an instance of a class is returned, do all properties get returned?

3 Answers3