C# Constructors, Properties, and Encapsulation

The first Product example created an empty object and assigned fields afterward. Between those steps the object had a null name and zero price, whether those values made sense or not. A constructor receives the information required to establish a valid starting state before the reference is returned to the caller.

A constructor has the same name as the class and no return type. new BankAccount("Amina", 100m) allocates the object and calls the matching constructor. If validation fails, object creation fails instead of releasing an invalid account into the program.

A property looks like field access to a caller but is implemented through get and set accessors. An auto-property such as public string Owner { get; private set; } lets any caller read Owner while limiting assignment to the BankAccount class.

Properties can compute a value, validate assignment, or restrict setters, but avoid hiding surprising expensive or state-changing work in a getter. A property should feel like reading or writing a characteristic; an action belongs in a method.

An invariant is a rule that should remain true whenever an object is available for use. For the account, Balance must not be negative. A public setter would allow account.Balance = -1000m from anywhere, bypassing the withdrawal rule. A private setter and a Withdraw method keep every valid change on a controlled path.

Encapsulation is not making every member private without thought. It means the type exposes what callers need while retaining enough control to keep its promises. Start with the narrowest useful access and widen it when a real collaborator requires more.

public void Deposit(decimal amount)
{
  if (amount <= 0m)
      throw new ArgumentOutOfRangeException("amount");

  Balance += amount;
}

The constructor throws for invalid starting arguments because a valid account cannot be created without them. Withdraw returns false for an ordinary rejected request such as insufficient funds. These are design choices: exceptions suit contract violations or failures a local caller cannot reasonably ignore, while return values suit expected alternative outcomes.

Do not mix policies randomly across similar operations. Consistent behavior helps callers use a type safely. When failure needs more information than true or false, return a focused result type or provide a Try-style method with clear output.