Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

getter and setter for List<  >?

Posted on 2013-06-28
4
Medium Priority
?
789 Views
Last Modified: 2013-06-28
I am not familiar with this syntax.

What is happening here with the getter and setter just sort of tacked on the end?

protected List<MerchantStates> merchantStates { get; set; }

Open in new window

0
Comment
Question by:Tom Knowlton
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
4 Comments
 
LVL 75

Expert Comment

by:käµfm³d 👽
ID: 39285817
It's an "automatic" property. It saves you from having to do this:

private List<MerchantStates> _merchStates;

protected List<MerchantStates> merchantStates
{
    get { return this._merchStates; }
    set { this._merchStates = value; }
}

Open in new window

0
 
LVL 5

Author Comment

by:Tom Knowlton
ID: 39285826
I see:

In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. They also enable client code to create objects. When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.



But List<  >   already has Add(   )

Why would you need a setter?
0
 
LVL 75

Accepted Solution

by:
käµfm³d   👽 earned 2000 total points
ID: 39285831
You're not modifying List<>; you're having the compiler create the equivalent of what I displayed above. If you do not use the { get; set; } syntax, then you have to do what I demonstrated in the snippet above. That is, you have to create a backing field (i.e. private member variable) that the property makes reference to. In this case, the backing field just happens to be of type List<MerchantStates>.

Because we've declared both a get and set, we can now do:

classInstance.merchantStates  = new List<MerchantStates>();

Open in new window


The fact that we used "{ get; set; }" doesn't affect this--we could have used the expanded version I demonstrated above.
0
 
LVL 5

Author Closing Comment

by:Tom Knowlton
ID: 39285838
Okay - I understand better now.

Wow - that is kinda cool.  : )

I'll have to remember this!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Just a quick little trick I learned recently.  Now that I'm using jQuery with abandon in my asp.net applications, I have grown tired of the following syntax:      (CODE) I suppose it just offends my sense of decency to put inline VBScript on a…
Introduction Hi all and welcome to my first article on Experts Exchange. A while ago, someone asked me if i could do some tutorials on object oriented programming. I decided to do them on C#. Now you may ask me, why's that? Well, one of the re…
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen. Visualize your data!  ... really see it To use the code to create a calendar from a q…
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…

610 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question