Differences in constructors using property vs field (field)

Question

namespace WMB.CieloB
{
     internal class FuncoesCielo
     {
           internal FuncoesCielo(int iDC, Boleto boleto) 
           {
                IDCliente = iDC;
                this.boleto = boleto;
            }

            public int IDCliente { get; set; } 

            internal Transaction PagamentoComToken()
            {
                 var holder = cielo.holder(IDCliente);
                 Order orderDadosDoboleto = cielo.order(boleto.BoletoId.ToString(), boleto.Valor );
            }
      }
}

I’m calling this class through:

namespace WMB.CieloB
{
    public class Cobrancas
    {

        public bool ExecutarRecorrenciaCompleto()
        {
            IDC = 3;
            var boleto = db.boleto.Find(1);//apenas exemplo
            var NewPagamento = new FuncoesCielo(IDC, boleto);
            var transacao = NewPagamento.PagamentoComToken();
}
}}

That is both the property Idclient and boleto will be available within the class, but one is property (Idclient), another is a field (Boleto) I normally declare a field equal to a variable in this case nor declare.

What is the difference between using the IDCliente as a method of this.boleto that has not even been declared (Boleto boleto;) but I can access it within the class.

Answer 1

First it’s good to understand well what a builder is for. Then it starts clearing up because it’s different to boot it or the property. Unless you’re using C#6 or higher and the initialize directly with a default value. The same can be done with the field, in all versions you can always initialize with default value. Otherwise, it is possible to initialize the public properties/fields on the object initialization. It has a similar effect to the constructor.

If the data is not initialized during the construction of the object, by constructor or not, its initial value will be a pattern of the created type. It will be a 0, a null, etc. And then it can be changed if the property/field allows this. Question that helps to understand this.

The fact that there is a property means that it can be accessed externally. Whether it can change its value or not depends on how it is declared. Remembering that it is common for a property to have a field to store the value, the state, even if it does not appear in the code, this field is usually private.

It is possible to use a public field to achieve the same effect, but this usually hurts abstraction/encapsulation and there is no granular control over access. Both reading and writing are public. Another question can help understand the property a little more.

Of course, if you have a private field only the class itself can access it. A private field can be accessed in the constructor or any method of it, but nothing from outside.

As for the field boleto accessible I would say that is impossible, mainly by being this.boleto, but I didn’t see the full context.

AP didn’t want to put a bigger context, so now I’m going to start speculating on the fact of the field boleto be accessible even without being declared in the class.

If the class inherits from one another and the other has a field with visibility protected, then you are accessing the base property field.

If there is a field in another class in the same Assembly visible internal would also give access to the other classes.

The way it is the code nor compiles.

After the edits the code got even weirder.