What are the cons of some code like this:
public class Class1
{
public object Property1
{
set
{
// Check some invariant , and null
// throw exceptions if not satisfied
// do some more complex logic
//return value
}
}
}
Private properties are useful for lazy initialization, and can be useful to ease debugging (since you can break on get and set) or to facilitate data in inspection. Lazy loading is not exception, cause you can use private field of type Lazy<Your type> , which removes need to use property.
The main difference between making a field public vs. exposing it through getters/setters is holding control over the property. If you make a field public, it means you provide direct access to the caller. Then, the caller can do anything with your field, either knowingly or unknowingly.
Properties enable a class to expose a public way of getting and setting values, while hiding implementation or verification code. A get property accessor is used to return the property value, and a set property accessor is used to assign a new value.
Properties can be marked as public , private , protected , internal , protected internal , or private protected . These access modifiers define how users of the class can access the property. The get and set accessors for the same property may have different access modifiers.
The con would be that if you are doing excessive logic that takes a great period of time, and/or has side effects which don't logically flow from the setting of the property, you are going to have a pretty convoluted class design.
Methods are traditionally used to indicate that an action with consequence is being performed, not properties. While you definitely can have logic in them, having too much might give the wrong impression of what you are trying to do, which is assign a value, as opposed to perform an operation.
In the end, it all depends on what "do some more complex logic" means.
It's hard to answer the question since "complex logic" is very vague.
I see no issues with basic sanity checking on setting of a property and it's very common to need to do some sort of processing on an object when one of its properties changes.
Now, if by "complex logic" you mean do things like some crazy database access or creating a network connection to go do something then yes, that would be bad.
If you see a property, you assume that it behaves just like a field, i.e., that you can retrieve its value over and over again:
if(obj.Prop.Equals(otherObj.Prop))
{
Console.WriteLine(obj.Prop);
Log.CreateEntry(obj.Prop);
}
Were Prop
implemented as a method. The users suspects expensive computation and will probably copy the result into a local variable and work on it instead.
A property must never change the object. A property should always return the same object if it's value hasn't changed. Especially if the creation of the object is expensive (like returning a new StreamReader on every call)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With