-
just because your project is a 1 or 2 man project, doesn’t mean you should ignore standards because “you guys understand your own unique standards”… because what if you have someone else join later on? What if you try and share said code? (this is not a reason for properties though, just wanted to point it out).
-
Properties
First, not all languages even have properties, and will instead insist on using methods/functions to do it. For instance Java insists on using functions with the shape ‘GetProp’ and ‘SetProp’
...
private int _value;
public void SetValue(int value) { _value = value; }
public int GetValue() { return _value; }
...
Languages like C# on the other hand have explicit property constructs for the interface of your classes and structs. They still end up functioning similar to methods/functions, just with unique identifiers.
They’re useful for a lot of things.
properties of value types are immutable:
a property that returns a value type (like a Vector3) can not be modified directly. Because a property is like a function returning a result, and the result is a value type, you receive a copy of the underlying value. You can’t say:
obj.position.x = 5.0f;
because you’re modifying a copy. Instead you say:
var v = obj.position;
v.x = 5.0f;
obj.position = v;
Now, you might be thinking. UGH, that’s annoying! Why would I want that? Well… maybe you want to protect your value. Maybe that value you’re storing needs to be validated when setting. This leads me to the next…
properties can run code:
a property can run code when setting and getting. I can validate incoming values, or even have properties that are actually combinations of other properties and aren’t directly stored.
private float _radius;
public float Radius
{
get { return _radius; }
set { _radius = Mathf.Abs(value); //radius is validated as always positive }
}
public float Diameter
{
get { return _radius * 2.0f; //diameter isn't an actual field, and this is actually a reflection of existing data }
set { this.Radius = value; }
}
Encapsulation
That previous thing has to do with encapsulation. That’s an example of encapsulation. Encapsulation is useful so that you can control the state of an object through its class with out the rest of your code base really caring about such business. It’s only concerned about the shape of the interface of the class. As long as that is the same… it can keep working. Speaking of interfaces…
Interfaces
I screw a screw with a screw-driver. The Interface construct is for explicitly defining the interface of classes. Yes, the two uses of the words mean 2 different things. An Interface is the construct in which you explicitly define a castable interface type. An interface is the implicit shape of a class, all its in and out methods (properties and methods).
An interface can’t have fields, because fields are data. Interfaces don’t define data, they define interfaces. So an interface can only define the properties and methods of a class, not the fields.
Now the game community is notorious for writing “hack code”. In that we write code that doesn’t meet the normal standards out there. There’s a few reasons behind this, mainly because the designs of video-games don’t fit nicely into normal paradigms, and instead we hack apart existing paradigms to get it done.
This means that your non-use of properties isn’t necessarily “bad” in the context of what you do. But nor is it good.
Now all of this may not appear that important to you. But your design patterns may not every really use the power of these tools. And that’s fine. That’s the thing about foreign or unused tools… you don’t know get first hand knowledge of what they can perform until you go and do something first hand with them.
But some of us do use these tools to exact powerful design patterns. Yes these patterns could be accomplished just using Functions as well… ala Java. But of course we like consistency, and if something acts like a property, we want to access it like a property.
