We Keep Coding

How to set a value for a private set in c#

So, I need to go through my code base and remove all the public setters and change them to private for immutable properties.
I know this will make it harder for me to set the values an I can do that through a constructor. Are there any other ways for me to set the value besides through a constructor?
The point is to limit the access on changing the value.

private string _value;
public SetValue(string value)
{
_value = value;
}
or
ctrl+. on property to encapsulate field

There are several methods that I use to create immutable properties in C#, when I also need to set that property outside of the constructor.
The first scenario is to throw an exception if the object is modified after being set
private object _myProperty;
public object MyProperty
{
public get { return _myProperty; }
public set
{
if(_myProperty == null) { _myProperty = value; }
else { throw new InvalidOperationException("MyProperty can't be changed onece set"); }
}
}
This method doesn't prevent errors before runtime but it can help you catch yourself when you're doing silly things.
Another method is to hide setters using an interface. By explicitly implementing an interface you can hide a property or method from a user unless they cast your class to that specific interface. This doesn't actually make your property immutable, but it helps protect properties from unintentional modification.
public interface MyInterface
{
object MyProperty { get; }
}
public interface MyInterfaceProtected
{
object MyProperty { set; }
}
public class MyClass : MyInterFace, MyInterfaceProtected
{
private object _myProperty;
public object MyProperty { get {return _myProperty;} }
object MyInterfaceProtected.MyProperty
{
set { _myProperty = value; }
}
}

It seems you are talking about C# 6 { get; }. Those properties are settable only from the constructor.
If you will define your property as { get; private set; } you will be able to set it from this class or in derived classes.

Changing variable type at runtime

I have a class hierarchy (In .Net 3.5) as shown:
Parent
- Child1
- Child2
- Child3
I have a base class as shown:
public abstract class BaseClass
{
protected Parent field;
public BaseClass(Parent someField)
{
this.field = someField
}
public string Property1
{
get { return field.Child1Property; }
set { field.Child1Property = value; }
}
}
The parameter that I'm passing in the constructor is going to be one of the Children. Is there a way to access the Child properties through a variable of the Parent type?
Alternately, is it possible to do this:
public abstract class BaseClass
{
protected Parent field;
protected Type childType; //Type? Or something else?
public BaseClass(Parent someField)
{
//assign the runtime type of someField to childType
this.field = someField
}
public string Property1
{
get { return ((childType)field).Child1Property; } //Is this possible?
set { ((childType)field).Child1Property = value; }
}
}
If I use Type it doesn't seem to work since ((childType)field).Child1Property is not allowed. The problem is, I only find out what type of child is being passed at runtime so casting the field to the appropriate type doesn't seem to be possible.
Help!

You can do this:
public abstract class BaseClass
{
protected Parent field;
public BaseClass(Parent someField)
{
this.field = someField
if (someField is Child1)
this.Property1 = ((Child1)someField).Foo();
}
public Int32 Property1
{
get { return field.Child1Property; }
set { field.Child1Property = value; }
}
}
However, there is a caveat here. You need to know that the instance of parent being passed in is of type Child1, or nothing will happen. Generally it's considered a bad design to have an if/then that covers every possible child class, because that means that when you add another child in the future, you'll need to remember to come back here and add it to the if/then.
The proper way to do this is really to have a property in Parent that is overriden in child:
public class Parent {
public virtual Int32 Foo() { return 5; }
}
public class Child1 : Parent {
public override Int32 Foo() { return 7; }
}
And then use that property:
public BaseClass(Parent someField)
{
this.field = someField
// If someField happens to be a Child1, this will be 7
this.Property1 = someField.Foo();
}

Looks like you propably want to use an Interface or generics.

When do we need to use [Browsable(true)]?

When do we need to use [Browsable(true)]?
EDIT (by SLaks): He's asking (I assume) why one would need to pass true as the parameter, given that it's already true by default.

As far as I know, never.
EDIT
I was wrong.
It's necessary if you want to make a property which has [Browsable(false)] in your base class (such as UserControl.Text) browsable.

MSDN says it all:
Specifies whether a property or event should be displayed in a Properties window.
For example, if you're creating a User Control, you might want to decorate non-UI-related properties with [Browsable(false)] so that they will not be available through a "Properties" window.
Additionally, it controls which properties of an object can be seen in a PropertyGrid.
As for why we can pass true explicitly, I believe this is due to BrowsableAttributes property of a PropertyGrid. You can set it to contain BrowsableAttribute.No, so that the property grid will display all non-browsable members.

Probably when you want to make damn sure no one changes it :P
// I want to see this, dont change it to false or I'll hunt you down...
[Browsable(true)]
public int MyProperty {
get {
// Insert code here.
return 0;
}
set {
// Insert code here.
}
}

The problem is that things are browsable by default. The only scenario I can think where this would matter is overriding a member and changing the browsability... here F is visible only because of the [Browsable(true)] in the derived class - without it, it isn't visible.
using System.ComponentModel;
using System;
using System.Windows.Forms;
static class Program
{
[STAThread]
static void Main() {
Application.EnableVisualStyles();
Application.Run(new Form { Controls = {new PropertyGrid {
Dock = DockStyle.Fill, SelectedObject = new Bar()
}}});
}
}
public class Foo
{
public virtual string A { get; set; }
public virtual string B { get; set; }
public virtual string C { get; set; }
[Browsable(false)] public virtual string D { get; set; }
[Browsable(false)] public virtual string E { get; set; }
[Browsable(false)] public virtual string F { get; set; }
[Browsable(true)] public virtual string G { get; set; }
[Browsable(true)] public virtual string H { get; set; }
[Browsable(true)] public virtual string I { get; set; }
}
public class Bar : Foo
{
public override string A { get { return base.A; } set { base.A = value; } }
[Browsable(false)] public override string B { get { return base.B; } set { base.B = value; } }
[Browsable(true)] public override string C { get { return base.C; } set { base.C = value; } }
public override string D { get { return base.D; } set { base.D = value; } }
[Browsable(false)] public override string E { get { return base.E; } set { base.E = value; } }
[Browsable(true)] public override string F { get { return base.F; } set { base.F = value; } }
public override string G { get { return base.G; } set { base.G = value; } }
[Browsable(false)] public override string H { get { return base.H; } set { base.H = value; } }
[Browsable(true)] public override string I { get { return base.I; } set { base.I = value; } }
}

BrowsableAttribute Class (System.ComponentModel)
The documentation states:
A visual designer typically displays
in the Properties window those members
that either have no browsable
attribute or are marked with the
BrowsableAttribute constructor's
browsable parameter set to true.
[Browsable] also defaults to true.
...so technically, you never need [Browsable(true)] unless you want to be very explicit.

One occassion when this attribute becomes important is during WebPart development for Sharepoint. In this scenario you are providing meta information for Sharepoint to determine whether your webpart should be viewable for selection etc. There are other similiar attributes such as Category and FriendlyName etc which are also taken into account.
See the following for examples:
Creating a web part with custom properties
And another with decent images of the sharepoint webpart editor which reflects your attributes:
Making Sharepoint WebParts interact

The types and attributes in ComponentModel are not specifically tied to any particular designer. Although I don't know of any specific scenario that you would need to "opt in" to being designer-browsable, I suppose it's conceivable that you could have some component designer that would assume browsable(false).
I suppose you could also override a virtual property that specified browsable(false) and apply browsable(true) in the overridden member.

A visual designer typically displays in the Properties window those members that either have no browsable attribute or are marked with the BrowsableAttribute constructor's browsable parameter set to true. These members can be modified at design time. Members marked with the BrowsableAttribute constructor's browsable parameter set to false are not appropriate for design-time editing and therefore are not displayed in a visual designer. The default is true.
so, the answer is you never have to, as it is done by default.

According to the documentation you want it to be true when it should be displayed in the property window in VS. Basically it applies to classes that are used in the designer.

Override get, but not set

I have an abstract class that defines a get, but not set, because as far as that abstract class is concerned, it needs only a get.
public abstract BaseClass
{
public abstract double MyPop
{get;}
}
However, in some of the derive class, I need a set property, so I am looking at this implementation
public class DClass: BaseClass
{
public override double MyPop
{get;set;}
}
The problem is, I got a compilation error, saying that
*.set: cannot override because *. does not have an overridable set accessor.
Even though I think that the above syntax is perfectly legitimate.
Any idea on this? Workaround, or why this is so?
Edit: The only approach I can think of is to put both get and set as in the abstract class, and let the subclass throws a NotImplementedException if set is called and it's not necessary. That's something I don't like, along with a special setter method .

One possible answer would be to override the getter, and then to implement a separate setter method. If you don't want the property setter to be defined in the base, you don't have many other options.
public override double MyPop
{
get { return _myPop; }
}
public void SetMyPop(double value)
{
_myPop = value;
}

New in C# 6.0:
If you are only calling the setter within your constructor, you can resolve this problem using read-only properties.
void Main()
{
BaseClass demo = new DClass(3.6);
}
public abstract class BaseClass
{
public abstract double MyPop{ get; }
}
public class DClass : BaseClass
{
public override double MyPop { get; }
public DClass(double myPop) { MyPop = myPop;}
}

It is not possible to do what you want. You have to define the setter in the abstract property, otherwise you won't be able to override it properly.
The only case I know where a getter is defined and a getter/setter are implemented is by using an interface:
public interface IBaseInterface
{
double MyPop { get; }
}
public class DClass : IBaseInterface
{
public double MyPop { get; set; }
}

If BaseClass is in your own codebase, then you can do:
abstract public class BaseClass
{
abstract public double MyPop { get; protected set; }
}
public class DClass : BaseClass
{
private double _myProp;
public override double MyProp
{
get { return _myProp; }
protected set { _myProp = value; }
}
}
EDIT: You can then go make a public method in DClass SetMyProp(double myProp) or the like. The class design for your domain model should be clear about or speak for itself why you can't set the property directly in the base class and why you can do so in the derived one.

Are you sure that doing what you are trying to do would be a good design if you found a way to do it?
It would allow objects of the subclass to make state changes that objects of the parent class can not make. Wouldn't that violate the Liskov Substitution Principle?

You could do something like this:
abstract class TestBase
{
public abstract int Int { get; }
}
class TestDerivedHelper : TestBase
{
private int _Int;
public override int Int
{
get
{
return _Int;
}
}
protected void SetInt(int value)
{
this._Int = value;
}
}
class TestDerived : TestDerivedHelper
{
public new int Int
{
get { return base.Int; }
set { base.SetInt(value); }
}
}
Using TestDerived will have the functionality you're looking for. The only drawback I can see from this method is that you have to implement every abstract method in TestDerivedHelper, but it gives you more control later.
Hope this helps. ;)

The reason that this is not possible is due to the way parameters are "Magicked" into existence by C#. When you define a parameter, C# creates a private field that the implicit getter and setter manipulate. If there is no setter in the base class, it's impossible to change this variable from a method written in a sub class (as the private flag prohibits even sub classes from accessing it). What usually happens is it uses the implicit setter of the base class instead.
I wouldn't advise putting the set in the base class if not all sub classes can do it, because this goes against the whole principle of polymorphic programming (any abstract method defined in the abstract class must be implemented by a subclass). Creating a special setter method, as described in other answers is probably the best way go.

Siege
abstract class TestBase
{
public abstract int Int { get; }
}
class TestDerivedHelper : TestBase
{
private int _Int;
public override int Int
{
get
{
return _Int;
}
}
protected void SetInt(int value)
{
this._Int = value;
}
}
class TestDerived : TestDerivedHelper
{
public new int Int
{
get { return base.Int; }
set { base.SetInt(value); }
}
}
Using TestDerived will have the functionality you're looking for. The
only drawback I can see from this method is that you have to implement
every abstract method in TestDerivedHelper, but it gives you more
control later.
I use this approach and works very well for me.
Also, I made my "TestDerivedHelper" class abstract too, then all the methods must be implemented on "TestDerived" class.

Even though this thread is old I'm positing my solution, in case it helps someone. It is not my own but is based off answers in other SO topics.
public abstract BaseClass
{
public double MyPoP { get { return GetMyPoP; } }
protected abstract double GetMyPoP { get; }
}
public class DClass: BaseClass
{
public new double MyPoP { get; set; }
protected override double GetMyPop { get { return MyPoP; } }
}
This solution adds an extra line of code for each such property that needs accessor modified. However, there is no change to external visibility and provides needed functionality.

public abstract class BaseClass
{
public abstract double MyPop { get; }
}
public class DClass: BaseClass
{
private double _myPop = 0;
public override double MyPop
{
get { return _myPop; }
}
// some other methods here that use the _myPop field
}
If you need to set the property from outside DClass then maybe it would be better to put the setter into the base class.

EDIT:
OK I may have been hasty with this response, but I've given it some more thought now.
Do you have to use an abstract base class? If it's not required, try this:
public interface ISomeRelevantName
{
double MyPop { get; }
}
public class DClass : ISomeRelevantName
{
public double MyPop { get; set; }
}

Why not just have a property in the base class that has a private setter, then in your subclass that needs the setter, override it and make it public.

You cannot override the set accessor since the base class has no set accessor defined.
What you can do is use the new keyword to hide the base classes implementation, but that may not be what you want.

Overriding fields or properties in subclasses

I have an abstract base class and I want to declare a field or a property that will have a different value in each class that inherits from this parent class.
I want to define it in the baseclass so I can reference it in a base class method - for example overriding ToString to say "This object is of type property/field".
I have got three ways that I can see of doing this, but I was wondering - what is the best or accepted way of doing this? Newbie question, sorry.
Option 1:
Use an abstract Property and override it on the inherited classes. This benefits from being enforced (you have to override it) and it is clean. But, it feels slightly wrong to return a hard-code value rather than encapsulate a field and it is a few lines of code instead of just. I also have to declare a body for "set" but that is less important (and there is probably a way to avoid that which I am not aware of).
abstract class Father
{
abstract public int MyInt { get; set;}
}
class Son : Father
{
public override int MyInt
{
get { return 1; }
set { }
}
}
Option 2
I can declare a public field (or a protected field) and explicitly override it in the inherited class. The example below will give me a warning to use "new" and I can probably do that, but it feels wrong and it breaks the polymorphism, which was the whole point. Doesn't seem like a good idea...
abstract class Mother
{
public int MyInt = 0;
}
class Daughter : Mother
{
public int MyInt = 1;
}
Option 3
I can use a protected field and set the value in the constructor. This seems pretty tidy but relies on me ensuring the constructor always sets this and with multiple overloaded constructors there is always a chance some code path won't set the value.
abstract class Aunt
{
protected int MyInt;
}
class Niece : Aunt
{
public Niece()
{
MyInt = 1;
}
}
It's a bit of a theoretical question and I guess the answer has to be option 1 as it is the only safe option but I am just getting to grips with C# and wanted to ask this of people with more experience.

Of the three solutions only Option 1 is polymorphic.
Fields by themselves cannot be overridden. Which is exactly why Option 2 returns the new keyword warning.
The solution to the warning is not to append the “new” keyword, but to implement Option 1.
If you need your field to be polymorphic you need to wrap it in a Property.
Option 3 is OK if you don’t need polymorphic behavior. You should remember though, that when at runtime the property MyInt is accessed, the derived class has no control on the value returned. The base class by itself is capable of returning this value.
This is how a truly polymorphic implementation of your property might look, allowing the derived classes to be in control.
abstract class Parent
{
abstract public int MyInt { get; }
}
class Father : Parent
{
public override int MyInt
{
get { /* Apply formula "X" and return a value */ }
}
}
class Mother : Parent
{
public override int MyInt
{
get { /* Apply formula "Y" and return a value */ }
}
}

Option 2 is a non-starter - you can't override fields, you can only hide them.
Personally, I'd go for option 1 every time. I try to keep fields private at all times. That's if you really need to be able to override the property at all, of course. Another option is to have a read-only property in the base class which is set from a constructor parameter:
abstract class Mother
{
private readonly int myInt;
public int MyInt { get { return myInt; } }
protected Mother(int myInt)
{
this.myInt = myInt;
}
}
class Daughter : Mother
{
public Daughter() : base(1)
{
}
}
That's probably the most appropriate approach if the value doesn't change over the lifetime of the instance.

You could do this
class x
{
private int _myInt;
public virtual int myInt { get { return _myInt; } set { _myInt = value; } }
}
class y : x
{
private int _myYInt;
public override int myInt { get { return _myYInt; } set { _myYInt = value; } }
}
virtual lets you get a property a body that does something and still lets sub-classes override it.

option 2 is a bad idea. It will result in something called shadowing; Basically you have two different "MyInt" members, one in the mother, and the other in the daughter. The problem with this, is that methods that are implemented in the mother will reference the mother's "MyInt" while methods implemented in the daughter will reference the daughter's "MyInt". this can cause some serious readability issues, and confusion later down the line.
Personally, I think the best option is 3; because it provides a clear centralized value, and can be referenced internally by children without the hassle of defining their own fields -- which is the problem with option 1.

You could define something like this:
abstract class Father
{
//Do you need it public?
protected readonly int MyInt;
}
class Son : Father
{
public Son()
{
MyInt = 1;
}
}
By setting the value as readonly, it ensures that the value for that class remains unchanged for the lifetime of the object.
I suppose the next question is: why do you need it?

If you are building a class and you want there to be a base value for the property, then use the virtual keyword in the base class. This allows you to optionally override the property.
Using your example above:
//you may want to also use interfaces.
interface IFather
{
int MyInt { get; set; }
}
public class Father : IFather
{
//defaulting the value of this property to 1
private int myInt = 1;
public virtual int MyInt
{
get { return myInt; }
set { myInt = value; }
}
}
public class Son : Father
{
public override int MyInt
{
get {
//demonstrating that you can access base.properties
//this will return 1 from the base class
int baseInt = base.MyInt;
//add 1 and return new value
return baseInt + 1;
}
set
{
//sets the value of the property
base.MyInt = value;
}
}
}
In a program:
Son son = new Son();
//son.MyInt will equal 2

You can go with option 3 if you modify your abstract base class to require the property value in the constructor, you won't miss any paths. I'd really consider this option.
abstract class Aunt
{
protected int MyInt;
protected Aunt(int myInt)
{
MyInt = myInt;
}
}
Of course, you then still have the option of making the field private and then, depending on the need, exposing a protected or public property getter.

I'd go with option 3, but have an abstract setMyInt method that subclasses are forced to implement. This way you won't have the problem of a derived class forgetting to set it in the constructor.
abstract class Base
{
protected int myInt;
protected abstract void setMyInt();
}
class Derived : Base
{
override protected void setMyInt()
{
myInt = 3;
}
}
By the way, with option one, if you don't specify set; in your abstract base class property, the derived class won't have to implement it.
abstract class Father
{
abstract public int MyInt { get; }
}
class Son : Father
{
public override int MyInt
{
get { return 1; }
}
}

I did this...
namespace Core.Text.Menus
{
public abstract class AbstractBaseClass
{
public string SELECT_MODEL;
public string BROWSE_RECORDS;
public string SETUP;
}
}
namespace Core.Text.Menus
{
public class English : AbstractBaseClass
{
public English()
{
base.SELECT_MODEL = "Select Model";
base.BROWSE_RECORDS = "Browse Measurements";
base.SETUP = "Setup Instrument";
}
}
}
This way you can still use fields.

The example implementation when you want to have an abstract class with implementation. Subclasses must:
Parameterize the implementation of an abstract class.
Fully inherit the implementation of the abstract class;
Have your own implementation.
In this case, the properties that are necessary for the implementation should not be available for use except for the abstract class and its own subclass.
internal abstract class AbstractClass
{
//Properties for parameterization from concrete class
protected abstract string Param1 { get; }
protected abstract string Param2 { get; }
//Internal fields need for manage state of object
private string var1;
private string var2;
internal AbstractClass(string _var1, string _var2)
{
this.var1 = _var1;
this.var2 = _var2;
}
internal void CalcResult()
{
//The result calculation uses Param1, Param2, var1, var2;
}
}
internal class ConcreteClassFirst : AbstractClass
{
private string param1;
private string param2;
protected override string Param1 { get { return param1; } }
protected override string Param2 { get { return param2; } }
public ConcreteClassFirst(string _var1, string _var2) : base(_var1, _var2) { }
internal void CalcParams()
{
//The calculation param1 and param2
}
}
internal class ConcreteClassSecond : AbstractClass
{
private string param1;
private string param2;
protected override string Param1 { get { return param1; } }
protected override string Param2 { get { return param2; } }
public ConcreteClassSecond(string _var1, string _var2) : base(_var1, _var2) { }
internal void CalcParams()
{
//The calculation param1 and param2
}
}
static void Main(string[] args)
{
string var1_1 = "val1_1";
string var1_2 = "val1_2";
ConcreteClassFirst concreteClassFirst = new ConcreteClassFirst(var1_1, var1_2);
concreteClassFirst.CalcParams();
concreteClassFirst.CalcResult();
string var2_1 = "val2_1";
string var2_2 = "val2_2";
ConcreteClassSecond concreteClassSecond = new ConcreteClassSecond(var2_1, var2_2);
concreteClassSecond.CalcParams();
concreteClassSecond.CalcResult();
//Param1 and Param2 are not visible in main method
}