Robert Martin称OOP需避免function pointers，为何C#仍有delegates？
Great question—let’s break this down clearly, because Robert Martin’s framing here is about design intent rather than absolute language rules, and C#’s delegates aren’t the same as the raw function pointers he’s referencing.
First: What Bob Martin Actually Meant by OOP “Disabling” Function Pointers
结构化编程禁用无限制的goto；函数式编程禁用assignment；面向对象编程（OOP）禁用function pointers。
Bob’s point isn’t that OOP languages can’t have any form of function references—he’s talking about paradigm-level constraints to prevent common sources of unmaintainable code. Each of these three paradigms solves a problem by restricting a powerful but easily misused feature:
- Structured programming curbs unconstrained
gototo avoid spaghetti code where control flow jumps arbitrarily. - Functional programming bans mutable assignment to eliminate unintended side effects and make code more predictable.
- OOP aims to eliminate unbound, raw function pointers—the kind you’d find in C, where a pointer is just a memory address pointing to a standalone function, with no connection to the data it operates on. The goal here is to enforce the core OOP principle: behavior should be tightly coupled with the data it manipulates.
Why C#’s Delegates Aren’t the “Bad” Function Pointers Bob’s Talking About
C# delegates are a type-safe, context-aware evolution of function references—they don’t violate OOP’s core goals, and here’s why:
- They carry context: When you bind a delegate to an instance method, it includes a reference to the object (
this) alongside the method. This means the delegate is tied to the data it operates on, which aligns with OOP’s data-behavior coupling. - Type safety is enforced: Delegates have strict signature requirements. The compiler checks that the method you assign matches the delegate’s parameter and return types—no unsafe casting of function addresses like you’d do in C.
- They’re encapsulated: Delegates don’t let you bypass a class’s public interface. You can only reference methods that are accessible to the caller, preserving encapsulation.
- Even when bound to static methods, delegates are still typed and managed by the runtime, avoiding the memory safety risks of raw pointers.
What’s Wrong With Raw Function Pointers (The Ones OOP Wants to Avoid)?
Raw function pointers (like in C) introduce several problems that OOP was designed to solve:
- Broken encapsulation: A raw function pointer can be used to directly manipulate an object’s internal state, bypassing its public methods. For example, you could pass a pointer to a function that modifies a private struct field, completely ignoring the class’s intended interface.
- No built-in context: You have to manually pass data to the function via the pointer, which creates loose coupling between functions and the data they operate on. This makes code harder to follow—you have to track which function goes with which data, instead of having an object that encapsulates both.
- Type unsafety: Raw pointers have no inherent type checking. You can cast a pointer to a function that takes an
intto one that takes astring, and the compiler might not catch it. This leads to runtime crashes or unpredictable behavior that’s hard to debug. - Poor maintainability: Tracking where a raw function pointer points is difficult, especially in large codebases. There’s no built-in way to see the call chain or verify that the pointer is valid, making debugging and refactoring a nightmare.
So Does C# Contradict Bob’s Point?
Not at all. Bob was talking about the design motivation of OOP: to move away from unbound, unsafe function pointers that break data-behavior coupling. C#’s delegates are a managed, type-safe way to use function references within the OOP paradigm—they enhance flexibility without reintroducing the problems raw pointers cause.
For what it’s worth, C# does support raw function pointers in unsafe code, but that’s a niche, opt-in feature for low-level scenarios—not the standard OOP workflow the language is designed for.
内容的提问来源于stack exchange，提问作者ebu_sho
