Private 'set' in C# - having trouble wrapping my brain around it

前端 未结 9 2413
傲寒
傲寒 2021-02-12 10:34

I\'ve seen a lot of example code written using something like (please forgive how horribly canned this is):

public class Test
{
   public object Thingy { get; pr         


        
相关标签:
9条回答
  • 2021-02-12 10:57

    Basically, it is a readonly property. If it was written in full (not as an auto property) you would simply leave out the setter.

    Two examples that are largely the same:

    class Foo1
    {
       public int Id { get; private set; }
       public Foo1()
       {
           Id = lastId ++;
       }
    }
    
    class Foo2
    {
       private int _id;  // could be readonly 
       public int Id { get { return _id; } }
       public Foo2()
       {
           _id = lastId ++;
       }
    }
    
    0 讨论(0)
  • 2021-02-12 10:59

    To answer the question of a common scenario where this might be used... In an MVP pattern, if your Model exposes some properties for your Presenter I would write

    public string Bazinga { get; private set; }
    

    Now, the Model can change this value but other classes that use it cannot.

    0 讨论(0)
  • 2021-02-12 11:00

    This is just laziness that comes about from auto-properties. Before auto properties were around, people would implement the getter and omit the setter for properties which are meant to be read-only.

    public class Test
    {
       private /*readonly*/ Type _thingy;
       public Type Thingy { get { return _thingy; } }
    }
    

    Hopefully, C# 5 will allow you to create auto-properties with a getter only - because that's what everyone wants. (They should make readonly setters in auto-props too, I need that badly)

    0 讨论(0)
  • 2021-02-12 11:03

    This syntax allows you to provide a public-facing property that appears read-only to consumers of your API but internally can be changing. By auto-implementing in this way, you avoid having to write boilerplate code such as a distinct setter or a backing field for the value, and you leave room in your design to add a bespoke set algorithm if it is deemed necessary at some point in the future without having to decide right away.

    0 讨论(0)
  • 2021-02-12 11:05

    private set is very handy for simple immutable value types.

    struct Point
    {
        public int X { get; private set; }
        public int Y { get; private set; }
        public Point(int x, int y)
        {
            this = default(Point);
            X = x;
            Y = y;
        }
    }
    
    0 讨论(0)
  • 2021-02-12 11:09

    This would be if you have a property that you don't want anyone to set but your class. This can be handy with database id's. The internal class can set it but you wouldn't want anyone else changing it. So you can give them read access but not write.

    EDIT: One more point on this is that using what you showed there is helpful for automatic properties. Unfortunately with automatic properties you are unable to only specify get so to avoid exposing a setter publicly it is just made private.

    EDIT: Just thought I would throw in an example. Automatic properties are great for clean, terse code. But like you showed there is a limitation in that you have to have get and set. So before it was like this for a property like you showed:

    public class Test
    {
       private object thingy;
       public object Thingy
       {
          get { return thingy; }
       }
    }
    

    Now we can get rid of that unneeded private declaration but it requires both. So make private to get around that.

    I know this was overkill on the explanation but different things kept popping in my head.

    0 讨论(0)
提交回复
热议问题