Есть ли лучший способ моделирования данных в F #, чтобы избежать необходимости?
Почему в F # нет защищенного модификатора доступа?
Ответ 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
.