I'd like to trigger a method every-time a value is changed in my list.
The top answer on other questions related to this is to use a property, which I have (example below)
However, I think it would help me prevent any accidental bugs if I deny anything other than that property having access to the 'core' list it changes (for lack of better understanding what the term is) .
Below is my example property with a get and set accessor.
private List<Things>myPrivateList; // Only the Property should be able to access
private List<Things>MyPrivateList // Only the class its in can touch this
{
get { return myPrivateList; }
set
{
myPrivateList = value;
coolMethodThatNeedsToRunEverytime();
}
}
public List<Things>getMyPrivateList // Any class outside can read this
{
get { return myPrivateList; }
}
I might be going about this the wrong way though, it would useful to know if you have any suggestions for what I'm trying to achieve. Thanks very much in advance for any advice / example you may have.
You can do what you want with one property :
public List<Things>MyPrivateList // Only the class its in can touch this
{
get { return myPrivateList; }
private set
{
myPrivateList = value;
coolMethodThatNeedsToRunEverytime();
}
}
Doing this, the setter will be private and the getter public
I am very new to .net .. I want to know What is Get, Set Properties ? I can't understand this? Please could anyone help me with some examples?
Get is called Accessor and Set is called Mutators in .Net
in Oops to preserve DataAbstraction concept we keeps Data member private in class.
now to access that data members from outside world we need some mechanism through which we can use it.
for this we define property which contains Accessor and Mutator.
with this we can give tremendous data abstraction.
you need them to have control over your object private fields values. for example if you don't wanna allow nulls or negative values for integers. Also, encapsulation is useful for triggering events on change of values of object members. Example
bool started;
public bool Started
{
get { return started; }
set
{
started = value;
if (started)
OnStarted(EventArgs.Empty);
}
}
another example
int positiveNumber;
public int PositiveNumber
{
get { return positiveNumber; }
set {
if (value < 0)
positiveNumber = 0;
else positiveNumber = value;
}
}
and also another implementation of read only properties could be as follows
int positiveNumber;
public int PositiveNumber
{
get { return positiveNumber; }
}
These are mutator method's, check Wikipedia for example and explanation, don't have to copy/paste that ;)
http://en.wikipedia.org/wiki/Mutator_method
You use properties as part of classes to store data.
public class MyClass
{
string ClassName { get; set;}
}
If you instantiate this class, you will be able to set its ClassName field.
These properties are then used within the class for methods to manipulate.
The Set will allow modification of the property. The Get will allow extraction of the data from the property. They are for property access.
I suggest you read some intro books on c# / vb.net to understand how to program first.
This will then enable you to understand more about what you asking.
Is there a way to do something like this in C#:
public class Class2 {
public string PropertyName1 { get
{
return this; //i mean "PropertyName1"
}
set {
this = value;
DoAdditionalFunction();
}
}
Because I need to call additional function in the "set" I need to have an extra private field like
private string _propertyName1;
public string PropertyName1 { get
{
return _propertyName1;
}
set {
_propertyName1= value;
DoAdditionalFunction();
}
I don't want to use additional property like _propertyName1. Is there a way to accomplish this or any best practices?
No - if you need any behaviour other than the most trivial "set a field, return the field value", you need to write "full" properties. Automatically implemented properties are only a shorthand for trivial properties.
Note that you haven't really got an "extra" private field, in terms of the actual contents of an object - it's just that you're explicitly declaring the private field instead of letting the compiler do it for you as part of the automatically implemented property.
(It's not clear what your first property is trying to do - setting this in a class is invalid, and you can't return this from a property of type string unless you've got a conversion to string...)
I often have a situation like this when creating simple data objects. I have a property called Label that should have a default based on the Name of the object. So if no label is set then the Name is used otherwise use the set Label. A simple example in C#
public class FooBat {
public string Name { get; set; }
public string Label {
get {
if (_label == null) return Name;
return _label;
}
set { _label = value; }
}
}
Now the problem is if you want to edit this object you can't just bind to the Label property or you will get the default value and it will look as if there is a value there when there really isn't. So what I end up doing is create another, read-only property that does the defaulting and I use that is all instances except for when the base object is being edited. This leads to many extra properties with weird names like LabelWithDefault. Another alternative I've tried is to make Label handle the defaulting and make a new property called RealLabel that is used for editing the base object. This is just as bad.
I've thought of moving the defaulting code somewhere else but I haven't found a good place for it in any "normal" model that does not replicate the defaulting code many times.
What I have started to do now is initialize the Label field when the Name field is set (and the Label field is not) and then treat the Label field as a normal field. This works but now the code for defaulting is tied to the wrong property. Why should the Name know that the Label field cares about it? So this is also not "right."
Does anyone have any better ways of handling this problem?
I think there is a little confusion about what I'm asking for. Basically I need two different views to the same object for two different uses. In the first is the editing of the object itself where I want unset fields to show as empty (unset). The second is for all other cases (including when the object is the value of a field of another object) where I want to show each field with its dynamically determined default. Just setting the default the first time doesn't no help because if the (in this case) Name field changes then the Label field must also change until the Label field is set.
The answers are getting closer but I still think that they are too targeted to the example I gave. I was trying to give a concrete example for expository purposes but in reality this is more of a best-practices issue. The example I gave was C# and for a string property but I have the same problem with most languages and systems that I use that have frameworks where the data access and data display are handled for you as well as for data types other than strings. Changing the object that is queried from the data source is possible but often tricky and knowing when to make the change (use a sublclass in this case but not in that one) is particularly difficult.
public class FooBat {
public string Name { get; set; }
public string Label {
get {
if (_label == null)
_label = Name;
return _label;
}
set { _label = value; }
}
}
Regarding your update:
You could subclass your object. The base-class would return null if the field has not been set and the sub-class would return your default value. Thus if you need to query if a value has been set, you would cast to the base-class.
Deleted previous answers/updates for brevity.
Update 2:
I would have to say the best way is to track whether the property has been set or not with an IsPropertySet bool. The Getter for the property would check that value to see if it should be returning its own value or the default value. And the setter for the property would set the IsPropertySet according to the set value (true if the value is not null, false if it is). The code that is using the class could then look at the IsPropertySet value to determine if it is receiving a set value or the default when it calls the Property's Getter.
public class FooBat {
public string Name { get; set; }
public bool IsLabelSet { get; set; }
public string Label {
get {
if (IsLabelSet)
return _label;
else
return Name;
}
set {
IsLabelSet = value != null;
_label = value;
}
}
}
I use a Nameable interface a lot (with getName()). Before I start, I'll suggest that you don't want to do this at all. It should be the domain of your display logic, not your domain objects. Usually it's the code consuming the FooBat that is able to make this decision in a better way than the object itself. That aside...
public interface Label{
string getLabel();
boolean isDefault(); //or isValued() or use instanceof expressions
}
public interface Nameable{
string getName();
}
public class FooBat implements Nameable {
public string Name { get; set; }
public Label Label {
get {
if (_label == null) {
_label = new DefaultLabel(this);
}
return _label;
}
set { _label = value; }
}
}
public class DefaultLabel implements Label{
public DefaultCharSequence(Nameable named){
this.named = named;
}
public string getLabel(){
return named.getName();
}
public boolean isDefault(){ return true; }
}
public class StringLabel implements Label {
...
}
It all essentially boils down to returning a better class for your label object.
Can anyone clearly articulate when you use a field and when to use a property in class design?
Consider:
public string Name;
Or:
private string _Name;
public string Name
{
get { return _Name; }
set { _Name = value; }
}
I realize that the second method is more proper and flexible, so that's what I try to use, generally.
But then why do I see people use the first method? Are they just lazy, or is there some specific situation where it's the correct choice? Is it just a matter of preference?
Well in C# 3.0 you can actually write:
public string Name {get; set;}
Which allows you to be proper and lazy.
Generally speaking, with properties, you get proper encapsulation. You have the choice to allow setting a value, or getting it, or both. Using a public member, you don't have that option.
It's probably one-part preference, and one-part how your team decides to handle quick and dirty class definitions, but I would say, use properties for get/sets.
To answer
Can anyone clearly articulate when you use an attribute and when to use a property in class design?
You shouldn't ever use a public attribute. You should always use a property instead. It's safer and more flexible. That said, people will be lazy, and just use a public member. However, with C# 3.0 you can use a more terse syntax to define properties, which should satisfy your inner laziness.
Simply type prop and hit <tab> to expedite the laziness in adding a property.
Just some additional information to Alan's reply:
public string Name {get; set;}
is the same as
private string _Name;
public string Name{
get { return _Name; }
set { _Name = value; }
}
If you want to disallow the set function of Name, you can have
public string Name {get; private set;}
Properties are more maintainable than fields, you can encapsulate logic in your setters/getters, allowing you to hide the implementation.
They also make refactoring easier.
More information:
Property Usage Guidelines
Field Usage Guidelines
Using properties you can control it's security:
public string Foo { protected get; private set; }
Properties gives easy way to raise events:
public string Foo
{
get { return _foo; }
}
set
{
bool cancel = false;
if(BeforeEvent != null) // EventHandler<CancelEventArgs> BeforeEvent
{
CancelEventArgs e = new CancelEventArgs();
BeforeEvent(this, e);
cancel = e.Cancel;
}
if(!cancel)
{
_foo = value;
if(AfterEvent != null) // EventHandler<EventArgs> AfterEvent
{
AfterEvent(this, new EventArgs());
}
}
}
Also I often use code like this:
string Foo
{
set
{
IsFooSet = value != null;
}
}
bool IsFooSet
{
get { return _isFoo; }
set
{
_isFoo = value;
if(value) // some event raise or controls on form change
}
}
When you make the field public, you allow the user to do whatever they want to do to the field. They can assign unexpected values, invalid values, values that can cause overflow, etc.
With the property, you have control over whether to allow the setting of new values to the field, massaging the value before storing it, notifying interested parties about the change of the field's value, etc. And the same idea for returning value through the getter. For .NET framework from 2.0 up, you can set the accessor for the getter, setter. Say, you only want the user to only have read access to the field, then you make the getter public, but the setter private or protected.
In addition to the already-given reasons for preferring properties, there's also lots of cool stuff in System.ComponentModel to do with data binding and change notification that only works with properties, rather than fields. For example, look at the documentation around PropertyChangedHandler.
A property like defined above acts like a getter and setter. The only benefits of using a property is that you can treat it like a variable with access restriction.
public string Name { get; private set; }
This property can be accessed publicly, but can only be set privately. (You wouldn't want anyone changing your name with out your consent now would you! ;) )