none
Question about class design best practice RRS feed

  • Question

  • I've been trying to find and answer to this question for some time so I hope it can be answered here.

    My question is regarding the use of properties (get/set) in a class that will not be exposed to the public.

    Is it better (i.e. more effecient, best practice, Microsoft way, etc) to use a property to facilitate the use of an external object within a class as in example 1.

    OR

    just use the external class's properties directly without a property as in
    example 2.

    It's obvious that there is less code in example 2, but I would like to know
    if there is or isn't a benefit in using a private property

    1. Using a Property
    namespace Reports

      class CustomerReport
      {
        EnterpriseObjects.Models.Customer _customer = Customer.Get(1234);
        private string _custFullName = string.Empty;
       
        [STAThread]
        static void Main(string[] args)
        {
          SetPropertyValues();
          ShowCustomerInfo();
        }
      
        private string FullName
        {
          get(return this._custFullName;}
          set(this._custFullName = value;
        }
       
        private void SetPropertyValues()
        {
           this.FullName = this._customer.FullName;
        }
       
        private void ShowCustomerInfo
        {
          ...
          report.Print(this.FullName);
        }
      }
    }

    2. No Property
    namespace Reports

      class CustomerReport
      {
        EnterpriseObjects.Models.Customer _customer = Customer.Get(1234);
       
        [STAThread]
        static void Main(string[] args)
        {
          ShowCustomerInfo();
        }
       
        private void ShowCustomerInfo
        {
          ...
          report.Print(this._customer.FullName);
        }
      }
    }

     

    Thanks in advance.

    Bill

    Tuesday, March 21, 2006 5:57 PM

Answers

  • I would say that in this example you are gaining little by using the properties; that said, they may make your life a bit easier at a later point if this report changes alot in the future. Jeffrey Richter writes a good deal on this in CLR via C#.

    On a side note I would be more inclined to create the report something along the lines of ..

     

    class CustomerReport {
         private Customer m_Customer;
         public CustomerReport(Customer _Customer) {
               m_Customer = Customer;
         }
    }

    than to place the logic for acquiring the customer within the report itself.

    Cheers,

    Greg

    Tuesday, March 21, 2006 9:53 PM

All replies

  • To answer your question first, I am not sure what Microsoft recommends but I would say that in general I would prefer to expose the properties of the underlying object wrapped in my own properties, that way I can control which properties are expose and which ones are not and I think the code is cleaner. You can still allow the user to set the properties of the child object directly but you could expose the most common properties for simplicity and clarity.

    One thing, you code will not compile, you are calling instance members from an static method, that will trigger a compilation error.

    You would have to create a separate class CustomerReport and create an instance to in your Main method or make the properties and methods static.

    If you do create a separate class, you will need to make the members non-private or you won't be able to access them.

    Tuesday, March 21, 2006 8:34 PM
  • I would say that in this example you are gaining little by using the properties; that said, they may make your life a bit easier at a later point if this report changes alot in the future. Jeffrey Richter writes a good deal on this in CLR via C#.

    On a side note I would be more inclined to create the report something along the lines of ..

     

    class CustomerReport {
         private Customer m_Customer;
         public CustomerReport(Customer _Customer) {
               m_Customer = Customer;
         }
    }

    than to place the logic for acquiring the customer within the report itself.

    Cheers,

    Greg

    Tuesday, March 21, 2006 9:53 PM
  • Thanks Greg for the reply. I guess there is not a "right or wrong" answer but I thank you for your insight.
    Tuesday, March 21, 2006 10:22 PM