I have a variety of methods that use a configuration object to fill in placeholders in a template. Different methods use different subsets of properties of the configuration object. I'd like an easy way to check that all the properties a given method uses are present in a given config object.
Right now I have a method like this:
private static void ValidateConfiguration(CustomerConfiguration config, params string[] properties)
This has the maintenance disadvantage that it relies on a separate set of strings for the properties used. What I'd love to do is have the validation method look at the calling method and see what properties of the config object are being accessed. Can this be done?
(I could also wrap String.Replace() in a method that checks for nulls, but that's less fun.)
A type safe way to handle your problem would be to implement several interfaces with different meaningful subsets of properties. My understanding is that the presence/absence of the properties in your case depends on the type of configuration object and is dynamic.
you could use a signature like that
ValidateConfiguration<T>(CustomerConfiguration config)
where T represent the interface and use reflection to list the required properties. While it would be practically impossible to parse the code of a method to infer its usages of a data structure, reflection on types (to extract properties) is fairly easy.
Different methods use different subsets of properties of the configuration object.
If you're only creating one instance of the configuration property, then the properties it needs to have are whichever ones are going to be used by any method. In other words, if at least one method needs that property, then the object needs that property.
In that case there's no need to validate it in relation to individual methods that need it. All of its properties need to be populated because they're all needed somewhere. If they're not needed anywhere, you can delete them.
Then, instead of validating that object based on the needs of a particular method, you validate it once, perhaps at startup. All of the properties are needed, so if they haven't been specified then the application just can't run. (Sometimes it's good to include defaults in your configuration object. You might have one property that you want to be able to configure, but in real life it's never going to change.)
If you're creating different instances of the same object for use in different methods and you only want to populate certain properties then it's better not to do that. Just create more granular objects for different scenarios containing all the properties you need.
What frequently happens is this: We have an object with lots of properties and we only use a few of them, so we populate those properties and pass the object to a method. The other properties are null.
Then, someone modifying that method decides that they need another property, so they try to use it, and they're surprised to find out that it's null. Then they have to go back and trace where that object was created and figure out what is populated or not. That's confusing and time-consuming.
Unless fields are entirely optional and it doesn't matter whether they are populated or not, we don't want to find ourselves looking at an object with lots of properties and guessing which ones have been populated because individual methods that create the object "know" which properties other classes do or don't need.
I'm starting to work with MongoDB using official c# driver. The problem is that I can't find a way to make bsonseriazer use fields (not properties) for setting the deserialized data and at the same time being able to use LINQ Api.
When mapping my class, I use BsonClassMap.FieldMap(). But this doesn't allow to use LINQ, since public properties remain unmapped.
Is there a way in BsonSerializer to do mappings based on properties, but at the same time specify that these should be set directly via their backing fields?
The reason I want to use fields for deserialization, is to omit custom validation rules that might be checked in setter.
I think you should keep those validation rules even when the data comes from your own database. It's much cleaner, less bug-prone and is more secure.
You can create your own BsonSerializers (or extend an existing one) that act which ever way you want. I've made several of those and it's really simple.
You can have a bool _isInitialized = false; in your DTOs that you set to true right after you get items from the MongoDB driver and forgo the validation rules until it is set.
I don't see another way to "split" the mapping to both the properties (for Linq) and data members (for serialization) and I recommend the first option.
I do not think this is a duplicate. I have done some reading but did not find anything the same as this. It seems that fields can be serialized in binary formatters and in protobuf but not in XML. I don't know about JSON.
I am looking at replacing the standard .NET binary serializer with protobuf-net. The reason is to improve speed and get a smaller persisted file size.
In NET Binary I just marked the classes as serializable and left it at that. Not good I suspect.
With protobuf-net I need to specify what gets serialized with the [ProtoMember()] attribute. My newbie testing shows that private fields get serialized if so marked as do auto properties.
I do not want to change the class code definitions at all since I still need to be able to deserialize the old persisted data created by the NET serializer. I have a mixture of:
Private fields that get used inside the class
Private fields whose value gets set in constructors
Private fields that are backing fields for non automatic properties
Properties with the backing fields above
Auto properties
Properties with no setters that return some calculation or value determined internally
and probably some others. In other words pretty much every type of field and property.
I guess I need to persist any value that represents the state of the object that cannot be constructed after deserialization from the file.
I suppose there would be no harm in persisting every field and property but that would just make the job slower and the file bigger than it needs to be.
I think I can ignore private fields that are used only inside the class and are not set from outside.
I think I should persist those fields that are set in constructors.
I am not sure about backing fields - is it better to persist them or their public property?
I must persist auto properties
I can't persist properties with no setters so I need to persist whatever fields/properties get used in their calculations.
Am I on the right track or missing the point.
Thanks in advance.
We can't say what needs to be serialized. BinaryFormatter works on an "all fields" basis (unless they are explicitly marked not for serialization). You could use the same approach, but if you're using automatically implemented properties (which is fine) then note that you cannot add attributes to the backing field - unlike field-like events, the following is not valid c#:
[field:ProtoMember(1)] // not valid
public int X { get; set; }
This means that your only sensible choice is to decorate the property:
[ProtoMember(1)]
public int X { get; set; }
Because, if you change the automatically implemented property to a regular property, you will have broken BinaryFormatter's deserialization, since the field-name will have changed. That's fine, though - there's nothing wrong with marking either the fields or the properties (or both in the same type) for serialization. Another consideration on some platforms is accessibility: a private field may be inaccessible, where-as a public field works fine. And obviously public fields are pretty uncommon.
So:
decide what needs to be serialized (I can't tell you this)
mark it for serialization
do not change anything from automatically-implemented property to a regular property if you need BinaryFormatter to keep working (protobuf-net doesn't care if you change this)
It is said that the designers of WPF have made it economical or higher performance. Can someone please explain with an example of what happens under the hood that makes the WPF property system more economical?
You are probably referring to the fact that Dependency Properties are "cheaper" than normal CLR properties.
In a few words:
Dependency properties are implemented using sparse data structures that only allocate memory for the property value if it is set on an object. In contrast, a standard CLR property value is stored as a field inside every object of the class in which the property is defined, even if all of these objects have the property set to its default value.
So for example, if we have 100 objects with 100 CLR properties of type int each, then we are using 10000 ints worth of memory even if all of those have the same default value (0).
If the property were a dependency property instead, we would not be using any additional memory at all: WPF does not need to remember the value of any property since it knows that you didn't change it from the default.
Of course the above is rather a simplistic explanation and does not cover all the advantages of dependency properties over CLR properties, but it should explain the "DPs have higher performance" statement adequately.
Most of the 'properties' of a WPF control are in fact not present on the Control itself. Instead of adding dozens of (mostly unused) properties to the (base-)classes, they elected to add a "property bag" instead, a Dictionary holding only the properties that are actually set.
As a bonus it allows for ambient and injected properties.
The WPF dependency property system stores actual property values in optimized data structures behind the scenes.
This has several advantages over storing property values as fields:
The dependency property system by NOT storing default values for properties for each object instance it can save allot of memory (basically if a property has a default value for a target object, space is not allocated for the value. This is opposed to the having properties with backing fields where the values are always stored, and the memory is always reserved for the object).
The dependency property system can have optimized event mechanism that avoids storing handler references on a per object basis (like using backing field based events), this means more space savings can be made.
There is of course a small overhead for such a system. Property access is not as lightweight as using a normal property, but the WPF team has decided the small overhead more than makes it up due to lower memory usage.
In addition to the other answers:
Dependency properties in WPF support property value inheritance. With normal CLR properties it is much harder to push values down to any "child" objects without modifying the child object. This can obviously be done with attached methods and a static mapping, but would probably not be a very generic solution. While there is some overhead with inherited properties, they are fairly efficient at passing down values.
Quick question: When do you decide to use properties (in C#) and when do you decide to use methods?
We are busy having this debate and have found some areas where it is debatable whether we should use a property or a method. One example is this:
public void SetLabel(string text)
{
Label.Text = text;
}
In the example, Label is a control on a ASPX page. Is there a principle that can govern the decision (in this case) whether to make this a method or a property.
I'll accept the answer that is most general and comprehensive, but that also touches on the example that I have given.
From the Choosing Between Properties and Methods section of Design Guidelines for Developing Class Libraries:
In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.
Yes, if all you're doing is getting and setting, use a property.
If you're doing something complex that may affect several data members, a method is more appropriate. Or if your getter takes parameters or your setter takes more than a value parameter.
In the middle is a grey area where the line can be a little blurred. There is no hard and fast rule and different people will sometimes disagree whether something should be a property or a method. The important thing is just to be (relatively) consistent with how you do it (or how your team does it).
They are largely interchangeable but a property signals to the user that the implementation is relatively "simple". Oh and the syntax is a little cleaner.
Generally speaking, my philosophy is that if you start writing a method name that begins with get or set and takes zero or one parameter (respectively) then it's a prime candidate for a property.
Searching through MSDN, I found a reference on Properties vs Methods that provides some great guidelines for creating methods:
The operation is a conversion, such as Object.ToString.
The operation is expensive enough that you want to communicate to the
user that they should consider caching
the result.
Obtaining a property value using the get accessor would have an observable
side effect.
Calling the member twice in succession produces different results.
The order of execution is important. Note that a type's properties should
be able to be set and retrieved in any
order.
The member is static but returns a value that can be changed.
The member returns an array. Properties that return arrays can be
very misleading. Usually it is
necessary to return a copy of the
internal array so that the user cannot
change internal state. This, coupled
with the fact that a user can easily
assume it is an indexed property,
leads to inefficient code.
If you're setting an actual property of your object then you use a property.
If you're performing a task / functionality then you use a method.
In your example, it is a definite property being set.
If however, your functionality was to AppendToLabel then you would use a method.
Properties are a way to inject or retrieve data from an object. They create an abstraction over variables or data within a class. They are analogous to getters and setters in Java.
Methods encapsulate an operation.
In general I use properties to expose single bits of data, or small calculations on a class, like sales tax. Which is derived from the number of items and their cost in a shopping cart.
I use methods when I create an operation, like retrieving data from the database. Any operation that has moving parts, is a candidate for a method.
In your code example I would wrap it in a property if I need to access it outside it's containing class:
public Label Title
{
get{ return titleLabel;}
set{ titleLabel = value;}
}
Setting the text:
Title.Text = "Properties vs Methods";
If I was only setting the Text property of the Label this is how I would do it:
public string Title
{
get{ return titleLabel.Text;}
set{ titleLabel.Text = value;}
}
Setting the text:
Title = "Properties vs Methods";
Symantically properties are attributes of your objects.
Methods are behaviors of your object.
Label is an attribute and it makes more sense to make it a property.
In terms of Object Oriented Programming you should have a clear understanding of what is part of behavior and what is merely an attribute.
Car { Color, Model, Brand }
A car has Color, Model and Brand attributes therefore it does not make sense to have a method SetColor or SetModel because symantically we do not ask Car to set its own color.
So if you map the property/method case to the real life object or look at it from symantic view point, your confusion will really go away.
You need only look at the very name... "Property". What does it mean? The dictionary defines it in many ways, but in this case "an essential or distinctive attribute or quality of a thing" fits best.
Think about the purpose of the action. Are you, in fact, altering or retrieving "an essential or distinctive attribute"? In your example, you are using a function to set a property of a textbox. That seems kind of silly, does it not?
Properties really are functions. They all compile down to getXXX() and setXXX(). It just hides them in syntactic sugar, but it's sugar that provides a semantic meaning to the process.
Think about properties like attributes. A car has many attributes. Color, MPG, Model, etc.. Not all properties are setable, some are calculatable.
Meanwhile, a Method is an action. GetColor should be a property. GetFile() should be a function. Another rule of thumb is, if it doesn't change the state of the object, then it should be a function. For example, CalculatePiToNthDigit(n) should be a function, because it's not actually changing the state of the Math object it's attached to.
This is maybe rambling a bit, but it really boils down to deciding what your objects are, and what they represent. If you can't figure out if it should be a property or function, maybe it doesn't matter which.
Properties should only be simple set and get one liners. Anything more and it should really be moved to a method. Complex code should always be in methods.
I only use properties for variable access, i.e. getting and setting individual variables, or getting and setting data in controls. As soon as any kind of data manipulation is needed/performed, I use methods.
As a matter of design Properties represent Data or Attributes of class object, While methods are actions or behaviors of class object.
In .Net, world there are other implications of using Properties:
Properties are used in Databinding, while get_ / set_ methods are not.
XML serialization user properties as natural mechanism of serilization.
Properties are accessed by PropertyGrid control and intern ICustomTypeDescriptor, which can be used effectively if you are writing a custom library.
Properties are controlled by Attributes, one can use it wisely to design Aspect Oriented softwares.
Misconceptions (IMHO) about Properties' usage:
Used to expose small calculations: ControlDesigner.SelectionRules's get block runs into 72 lines!!
Used to expose internal Data structures: Even if a property does not map to an internal data member, one can use it as property, if its an attribute of your class. Viceversa, even if its an attribute of your class properties are not advisable, to return array like data members (instead methods are used to return deep copy of members.)
In the example here it could have been written, with more business meaning as:
public String Title
{
set { Label.Text = text; }
}
Also big plus for Properties is that value of property can be seen in Visual Studio during debugging.
I prefer to use properties for add/set methods with 1 parameter. If parameters are more, use methods.
Properties are really nice because they are accessible in the visual designer of visual studio, provided they have access.
They use be used were you are merely setting and getting and perhaps some validation that does not access a significant amount of code. Be careful because creating complex objects during validation is not simple.
Anything else methods are the preferred way.
It's not just about semantics. Using properties inappropriate start having weirdness occur in the visual studio visual designer.
For instance I was getting a configuration value within a property of a class. The configuration class actually opens a file and runs an sql query to get the value of that configuration. This caused problems in my application where the configuration file would get opened and locked by visual studio itself rather than my application because was not only reading but writing the configuration value (via the setter method). To fix this I just had to change it to a method.
Here is a good set of guidelines for when to use properties vs methods from Bill Wagner
Use a Property when all these are true:
The getters should be simple and thus unlikely to throw exceptions. Note that this implies no network (or database) access. Either might fail, and therefore would throw an exception.
They should not have dependencies on each other. Note that this would include setting one property and having it affect another. (For example, setting the FirstName property would affect a read-only FullName property that composed the first name + last name properties implies such a dependency )
They should be settable in any order
The getter does not have an observable side effect Note this guideline doesn't preclude some forms of lazy evaluation in a property.
The method must always return immediately. (Note that this precludes a property that makes a database access call, web service call, or other similar operation).
Use a method if the member returns an array.
Repeated calls to the getter (without intervening code) should return the same value.
Repeated calls to the setter (with the same value) should yield no difference from a single call.
The get should not return a reference to internal data structures (See item 23). A method could return a deep copy, and could avoid this issue.
*Taken from my answer to a duplicate question.
This is simple.
1: use property when you want your data should be validated before storing in field. So in this way property provides encapsulation for your fields. Because if you leave your fields public end user may assign any value which may or may not be valid as per your business requirement like age should be greater than 18. So before value is store corresponding field we need to check its validity. In this way properties represent data.
2: Use method when you want perform some action like you are supplying some data as parameter and your method is doing some processing on the basis of supplied values and returning processed value as output. Or you want to change value of some field by this calculation. "In this way method represents action".
I come from java an i used get.. set.. method for a while.
When i write code, i don't ask to my self: "accessing this data is simple or require a heavy process?" because things can change (today retrive this property is simple, tomonrow can require some or heavy process).
Today i have a method SetAge(int age) tomonrow i will have also method SetAge(date birthdate) that calculate the age using the birthdate.
I was very disappointed that the compiler transform property in get and set but don't consider my Get... and Set.. methods as the same.