答案 0 :(得分:5)
像PatrykĆwiek一样,我也认为不可能,但这里有一个选择:
从Design Patterns我们知道我们应该赞成撰写而不是继承。根据我的经验,你可以用继承做的一切,你也可以用Composition。例如,您始终可以使用策略替换模板方法。
模板方法是抽象方法的典型用法,但如果将其替换为策略,则可以(从某种程度上)将其隐藏在客户端中:
type Foo(strategy : IBar) =
member this.CreateStuff() =
// 1. Do something concrete here
// 2. Use strategy for something here
// 3. Do something else concrete here
// 4. Return a result
Foo
的外部客户端无法调用strategy
,因此可以实现与保护成员相同的目标。
你可能会争辩说Foo
的原始创建者可以保留对strategy
的引用,并且仍然可以调用它。这是真的,但受保护的成员也不是真正完全隐藏,因为你经常可以从有问题的类派生,这使你能够调用受保护的成员。
另一点是,如果您将Foo
的创建者与Foo
的客户分开,则strategy
将无法供客户使用。