C
C#•3w ago
Faker

✅ Difference between property, method and fields.

Hello guys, I know there is a difference between method and fields, with method representing an "action" while the field an "attribute" of an object. But what about property? I know that when we declare a new class for e.g, their is something called as the "automatically implemented properties"; I know that these are setters and getters implemented using simple line of codes. Then I encountered this phrase: The properties of an exception object can be accessed within the catch block. For example, you can use the Message property to inform the application user of an issue. This is where I got a bit confuse; I notice the word "properties" is being used. So anytime I came across this word, how to think of this term? Why is it important/useful? Why not simply stick to fields and methods?
19 Replies
Angius
Angius•3w ago
$structure
MODiX
MODiX•3w ago
namespace Namespace;

[Attribute]
public class Class
{
    public string PublicField;
    private bool _privateField;    

    public int PublicProperty { get; set; }

    public Class() {} // Constructor

    public void Method(int parameter)
    {
        var localVariable = parameter; 

        int LocalMethod(string param) { return 3; }
    } 
}
namespace Namespace;

[Attribute]
public class Class
{
    public string PublicField;
    private bool _privateField;    

    public int PublicProperty { get; set; }

    public Class() {} // Constructor

    public void Method(int parameter)
    {
        var localVariable = parameter; 

        int LocalMethod(string param) { return 3; }
    } 
}
Angius
Angius•3w ago
General rule of thumb is that fields are private and properties are public They encapsulate a backing field, like getter and setter methods in lesser languages $getsetdevolve
MODiX
MODiX•3w ago
class Foo
{
    private int _bar;

    public int GetBar()
    {
        return _bar;
    }

    public void SetBar(int bar)
    {
        _bar = bar;
    }
}
class Foo
{
    private int _bar;

    public int GetBar()
    {
        return _bar;
    }

    public void SetBar(int bar)
    {
        _bar = bar;
    }
}
can be shortened to 
class Foo
{
    private int _bar;

    public int GetBar() => _bar;

    public void SetBar(int bar) => _bar = bar;
}
class Foo
{
    private int _bar;

    public int GetBar() => _bar;

    public void SetBar(int bar) => _bar = bar;
}
can be shortened to 
class Foo
{
    private int _bar;
    public int Bar {
        get { return _bar; }
        set { _bar = value; }
    }
}
class Foo
{
    private int _bar;
    public int Bar {
        get { return _bar; }
        set { _bar = value; }
    }
}
can be shortened to 
class Foo
{
    private int _bar;
    public int Bar {
        get => _bar;
        set => _bar = value;
    }
}
class Foo
{
    private int _bar;
    public int Bar {
        get => _bar;
        set => _bar = value;
    }
}
can be shortened to 
class Foo
{
    public int Bar { get; set; }
}
class Foo
{
    public int Bar { get; set; }
}
Angius
Angius•3w ago
This example shows well what properties are
Faker
FakerOP•3w ago
yep, we just use them as a way to set and retrieve value? like only as a sort of getters and setters "controller" ?
Angius
Angius•3w ago
As getters and setters, yeah
Faker
FakerOP•3w ago
yep I see, is it correct to say the following: Properties are always public, they are used mainly as getters and setters and when we use a property, behind the scenes, a backing field is also created but if we need to adjust the logic of the getters/setters, we need to create the backing field, like private string _backingField as well as we need to have the property.
Angius
Angius•3w ago
For now, at least, yeah We're gonna get a magic field keyword soon-ish
Faker
FakerOP•3w ago
ah ok, yeah heard of that (someone once mentioned it). I will just stick with that for now. Thanks !!! what will be the purpose of the magic keyword by the way ?
Sehra
Sehra•3w ago
no need to define the backing field, it's generated but you can refer to it as field inside the getter and setter
Faker
FakerOP•3w ago
oh ok I see but for now we don't have this functionality yet ?
Angius
Angius•3w ago
Alas
Sehra
Sehra•3w ago
if you set lang version to preview you do
Faker
FakerOP•3w ago
Ok, noted thanks but will just use the old fashion way rather than the field keyword for now, until the release
FusedQyou
FusedQyou•3w ago
Btw you generally make a field private, but I don't think it was mentioned why Generally you want to make everything as restrictive as possible, and only expose specific bits you need With variables you add/use a property as it is expected to be exposed compared to a field, due to the explicit getter/setter you can define However, mainly with (readonly) structs that exist for faster performance, you could just define public fields over properties It's preference on how you want to define these in case they are fully public, but note properties are more often expected here.
Faker
FakerOP•3w ago
yep I see by the way, we is it important to make things private? Because at the end of the day, the only person who will have access to the source code is the developer itself, no?
FusedQyou
FusedQyou•3w ago
Even if you are the sole user of the code you should restrict yourself and make everything as private as possible. The main purpose is keeping it clear how your states are mutates. Generally only the class should be able to change its own state, and any outside input/output should be clear and validated. What you said is wrong, though. For exmaple, a class library released publicly can be added to another person's project as a package. See how making it all public can be confusing to them? Let alone they probably misuse the way states are handled.
Faker
FakerOP•3w ago
ahhh I see yep noted, thanks !

Did you find this page helpful?