Differences in Constructors Using Property vs. Field

3

What's the difference between:

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();
}
}}
  

In other words, both the CustomerID and the ticket property will be available   within the class, but one is property (CustomerID), another is a field   (Boleto), I normally declare a field equal to a variable in this case and I declare.

What difference does the IDCliente use as a method than this.boleto that has not been declared ( Boleto boleto; ) but can access it within the class.

    
asked by anonymous 22.04.2016 / 14:31

1 answer

3

It's good to understand what a builder is for . Then it starts to lighten because it is different to initialize on it or on the property. Unless you are using C # 6 or higher and boot directly with a default value . The same can be done with the field, in all versions can always boot with default value. Otherwise, you can initialize the public properties / fields at object startup. It has a similar effect to doing in the constructor.

If the data is not initialized during the construction of the object, by constructor or not, its initial value will be a standard 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 understand this .

The fact that a property exists means that it can be accessed externally. Whether or not it can change its value depends on how it is stated. Remembering that every property always has a field to store the value, state, even if it does not appear in the code. This field is private.

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

Obviously, 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 out of the way.

As for the boleto accessible field I would say that it is impossible, mainly because it is this.boleto . But I did not see the full context.

The AP did not want to put a larger context, so now I'm going to start speculating about the fact that the boleto field is being accessible even without being declared in the class.

If the class inherits from another and has a field with protected visibility, then it is accessing the base property field. But there it would be base.boleto , could not be this .

If there is a field in another class in the same assembly with visibility internal it would also give access to the other classes. But again it could not be this .

The way it is, the code does not even compile .

After the edits, the code got even weirder.

    
22.04.2016 / 15:16