PHP与C#父类访问子类protected成员差异：谁符合OOP原则？

Great question! Let’s unpack this clearly, starting with the code examples and then diving into the OOP principles at play—especially encapsulation and the Liskov Substitution Principle (LSP).

PHP Code (Runs Without Errors) #

class A { 
    public static function echoes($b) { 
        echo $b->protectedFunction(); 
    } 
} 
class B extends A { 
    protected function protectedFunction() { 
        return "this is protected"; 
    } 
} 
$b = new B(); 
A::echoes($b);

C# Code (Throws Compilation Error) #

public class A
{
    public static void Echoes(B b)
    {
        // Error: 'B.protectedFunction()' is inaccessible due to its protection level
        Console.WriteLine(b.protectedFunction());
    }
}

public class B : A
{
    protected string ProtectedFunction()
    {
        return "this is protected";
    }
}

// Usage
var b = new B();
A.Echoes(b);

Why the Difference? Protected Member Visibility Rules #

The split comes down to how each language enforces protected access:

• PHP: Uses a hierarchy-based check. If the calling class (A) is part of the inheritance chain of the class that defines the protected member (B), access is allowed. It’s a flexible approach that prioritizes inheritance relationships over execution context.
• C#: Uses a context-based check. Protected members are only accessible within the defining class’s own code or within a subclass’s code. A parent class can’t directly access a subclass’s protected member through a subclass instance—because the parent isn’t operating within the subclass’s implementation context. Think of protected members as "family secrets": the child gets to decide when and where those secrets are shared, even with their parent.

Which Implementation Follows OOP Principles? #

Strictly speaking, C#'s approach aligns better with core OOP principles:

1. Encapsulation: Protected members are meant to encapsulate internal implementation details that only the class and its subclasses need to know. Allowing a parent to access a subclass’s protected member breaks this encapsulation—it forces the subclass to keep that member intact even if it wants to refactor, creating unnecessary coupling.
2. Liskov Substitution Principle (LSP): LSP requires that subclasses can replace their parent types without breaking the program. If a parent class relies on a subclass’s protected member, it’s no longer depending on its own abstract contract—it’s depending on a specific subclass’s implementation. Swap B for another subclass of A that doesn’t have ProtectedFunction, and the parent’s code breaks, violating LSP.

PHP’s behavior is a deliberate design choice that trades strict encapsulation for flexibility, but it deviates from the classical OOP intention of protected members.

内容的提问来源于stack exchange，提问作者apokryfos