Delphi Private Visibility: Ensuring Class‑Level Encapsulation in Shared Units

Preventing Cross-Class Private Access

To guarantee that a class's internal fields remain inaccessible to other classes within the same source unit, the most effective practice is to replace the private visibility specifier with strict private.

The Difference Between Private and Strict Private

In Delphi, the private keyword does not provide true class-level encapsulation; it provides unit-level visibility. Any procedure, function, or class defined within the same unit can access the private members of any other class in that unit. This behavior is a legacy design intended to simplify the creation of helper functions and tightly coupled internal logic.

The strict private specifier restricts access exclusively to the class itself and its descendants. This prevents other classes in the same unit from accessing those members, effectively enforcing a hard boundary at the class level.

Implementation Steps

1. Identify fields or methods that must be hidden from other classes in the shared unit.
2. Change the section header from private to strict private.
3. Compile the project to identify any existing unit-level dependencies (such as helper functions) that now trigger compiler errors.

type
  TInternalManager = class
  strict private
    FSecretKey: string; // Inaccessible to TExternalController
  public
    procedure Process;
  end;

  TExternalController = class
    procedure UpdateManager(AMgr: TInternalManager);
  end;

Static Analysis and Compiler Warnings

There is currently no native compiler warning or standard static-analysis flag in the Delphi compiler that can detect or alert you to cross-class private member access. Because the compiler treats unit-level access as legal behavior, it cannot flag it as a violation. To prevent these leaks, you must either use strict private or split the classes into separate units.

Trade-offs and Assumptions

This solution assumes you are using a modern version of Delphi that supports the strict private modifier. Note that while strict private solves the encapsulation problem, it may break existing unit tests or internal utility functions that rely on unit-wide access. If you find yourself needing to grant access to a specific "friend" class, you may need to reconsider the unit architecture or use a protected interface.