Подтвердить что ты не робот

Почему в F # нет защищенного модификатора доступа?

Есть ли лучший способ моделирования данных в F #, чтобы избежать необходимости?

4b9b3361

Ответ 1

Модификатор protected может быть довольно проблематичным в F #, потому что вам часто приходится вызывать участников из лямбда-выражения. Однако, когда вы это делаете, вы больше не получаете доступ к методу из класса. Это также вызывает путаницу при использовании защищенных членов, объявленных в С# (см., Например, этот вопрос SO). Если вы можете объявить член protected, следующий код может быть неожиданным:

type Base() = 
  protected member x.Test(a) = a > 10

type Inherited() = 
  inherit Base()
  member x.Filter(list) =
    list |> List.filter (fun a -> x.Test(a))

Этот код не работает, потому что вы вызываете Test из лямбда-функции (которая является другим объектом, чем текущий экземпляр Test), поэтому код не будет работать. Я думаю, что это основная причина не поддерживать модификатор protected в F #.

В F # вы обычно используете наследование реализации (то есть наследуете от базового класса) гораздо реже, чем на С#, поэтому вам не нужно protected так часто. Вместо этого обычно предпочтительнее использовать интерфейсы (в объектно-ориентированном коде F #) и функции более высокого порядка (в функциональном коде). Однако трудно сказать, как избежать необходимости protected вообще (кроме как избежать наследования реализации). У вас есть какой-то конкретный пример, который мотивировал ваш вопрос?

Ответ 2

Что касается того, дает ли F # лучший способ моделирования данных, файлы подписи разрешают более мелкие решения видимости, чем internal на С#, что часто очень приятно. См. Комментарий Брайана здесь для немного большего объяснения. Однако это не зависит от поддержки (или ее отсутствия) для protected.