2014-03-06 5 views
2
  • F # не поддерживает определение методов protected. Здесь поясняется why
  • F # заменяет методы virtual методами abstract, определенными в абстрактных классах (см. here).

Мне было интересно, есть ли способ предотвратить доступ к методам abstract извне производных классов вообще.защищенные виртуальные методы в f #

+3

Я не думаю, что это возможно - вы действительно спрашиваете, есть ли способ сделать метод 'protected', который не поддерживается. :) Может быть, есть другой подход к проблеме, которую вы пытаетесь решить, хотя нам, вероятно, потребуется более подробная информация. –

+0

Ну, я полагаю, в этом все сказано. Тем не менее, я счел, что это вопрос, который стоит задать: там может существовать творческий обход. – NoIdeaHowToFixThis

+0

Будет ли «внутренняя» работать для ваших целей? – Daniel

ответ

5

Как Patryk Ćwiek, я также не думаю, что это возможно, но вот одна альтернатива:

Из Design Patterns мы знаем, что мы должны одолжение состав над наследования. По моему опыту, все, что вы можете сделать с Inheritance, вы также можете сделать с композицией. Например, вы всегда можете заменить Template Method на Strategy.

Шаблон Метод является типичным использованием абстрактного метода, но если вы замените его стратегию, вы можете (вроде) скрывать от клиентов:

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 будет недоступен для клиента.

Смежные вопросы