Blocking Access to Private Member Variables? Force Use of Public Properties

Blocking access to private member variables? Force use of public properties?

No there is not a way to do that, other than to simply follow your own convention and do this.Hello if you really need to go through your public property.

I don't see why you would need/want to do this either, as since it is your internal class, you are the one in control of the code and you can define what/how it is used, so there shouldn't be an issue.

force get/set access of private variables for private properties

Sounds like you need a angle type.

// Non mutable Angle class with a normalized, integer angle-value
public struct Angle
{
  public Angle(int value)
  {
    Value = value;
  } 

  private angle;
  public Value 
  { 
    get { return angle; } 
    private set { angle = Normalize(value); } 
  }

  public static int Normalize(int value)
  {
     if (value < 0) return 360 - (value % 360);
     return value % 360;
  }
}

public class SomeClass
{
  public Angle EyeOrientation { get; set; }
}

If you have a certain kind of value, like angles, money, weight or whatever, it is always a good praxis to make it a own type, even if the value itself is stored in a int, decimal etc. This type makes your interfaces clearer and typesafe. It is not the same if you expect an Angle or a integer value as argument of some method.

Make member only accessible through property even in owner class?

Is there a way to make a compile-time checking?

No, class A is supposed to know that it has to call the method each time the private field is set. This is part of the internal logic that the class actually implements.

The compiler cannot stop you from setting a private field without calling a method first. This will be the responsibility of the developer of the class and not the compiler.

Prevent a class from access to one of its own field

No. There is no way to prevent a class accessing its own field if you want to Set its value at some point in an accessor.

Why can I access to the Private properties when using constructor parameters inside the same class

You seem to assume that private cares for the instance - which it obviously does not. In fact you don´t even need an instance - e.g. on a static member.

So if or if not you may access a member of a class depends on two factors:

1. are you within the same scope as that member?
2. do you have access to the instance to which the member belongs?

In your case your member is private, which makes the members scope the class-level. TestMethod is a method within that class, so point one matches.

You have two different instances. As you´re within TestMethod you can of course access the members of this (the current instance). Furthermore you have a reference to the newly created instance t. So point 2 also applies and you can access both members of both instances.

As an aside to point 2: If the member is static, there´s no instance, you can allways access it from within another instance.

How to hide the backing field from the rest of the class

you can move that logic to an abstract base class:

public abstract class Brittle
{
    private string _somethingWorthProtecting;
    public string SomethingWorthProtecting 
    {
        get { return _somethingWorthProtecting; }
        set
        {
            _somethingWorthProtecting = value;
            ReallyNeedToDoThisEverTimeTheValueChanges();
        }
    }

    //.....
}

then you can be sure no one will instantiate this class, and derived classes will not be able to access the private field.

public class BrittleDerived : Brittle
{
     public void DoSomething() 
     {
        // cannot access _somethingWorthProtecting;
     }
}

It is allowed to put private variables inside public methods in C#?

Yes its a very fundamental programming philosophy called encapsulation. Its perfectly valid and encouraged to do so. In your case, only you know how to use your connection object and "restrict" how to use it via your public method, thus keeping your application in your defined bounds.

Using public properties for internally and public usage or separate it?

Getters and Setters are highly overused.
I’ve seen millions of people claiming that public fields are evil, so they make them private and provide getters and setters for all of them. I believe this is almost identical to making the fields public, maybe a bit different if you’re using threads (but generally is not the case) or if your accessors have business/presentation logic (something ‘strange’ at least). I’m not in favor of public fields, but against making a getter/setter (or Property) for everyone of them, and then claiming that doing that is encapsulation or information hiding… ha!
by Pablo Fernandez ref: this and 19 other controversial programming opinions

To address the question, I've used both and the first option is the simplest. It is when some side effect occurs within the property getter/setter that the question is a little more difficult to answer. A typical example is when an event is raised to indicate the property has changed. Is that something that can occur both within the class and from an external request? In that case using the property rather than the backing variable will give consistent behaviour. So the best answer is it depends :-)

Private properties in JavaScript ES6 classes

Private class features is now supported by the majority of browsers.

class Something {
  #property;

  constructor(){
    this.#property = "test";
  }

  #privateMethod() {
    return 'hello world';
  }

  getPrivateMessage() {
      return this.#property;
  }
}

const instance = new Something();
console.log(instance.property); //=> undefined
console.log(instance.privateMethod); //=> undefined
console.log(instance.getPrivateMessage()); //=> test
console.log(instance.#property); //=> Syntax error

Custom Attribute to Ensure Encapsulation

No, that is not possible. ObsoleteAttribute has a special mention in the C# specification regarding how the compiler itself responds to it.

You could implicity restrict a variables use to a single property by using auto implemented properties.

public class Test
{
  public object Foo { get; set; }
}

Edit: If you wanted special logic handled independently in the getter and setter you could try the following code. This seems awfully obnoxious to me though.

public class Test
{

  private PrivateMembers Members { get; set; }

  public object Foo
  {
    get
    {
      return Members.Foo;
    }
    set
    {
      Members.Foo = value;
      // Do something else here.
    }
  }

  private class PrivateMembers
  {
    public object Foo { get; set; }
  }
}

---

Related Topics