2016-03-09 2 views
2

Мне было интересно, может ли кто-нибудь подумать о сценарии, в котором будет применяться следующее.C# Внутренний модификатор доступа

public class A 
{ 
    private class B 
    { 
     internal string s { get; set;} 
    } 
} 

Так что я знаю, что внутренние средства, что только классы в той же сборке имеют доступ, но и в предыдущем случае, это не будет применяться, поскольку класс B является частным. Мне было просто любопытно, может ли этот сценарий использовать случай. В случае использования я имею в виду, когда-либо было время, чтобы сделать модификатор доступа внутренним внутри частного класса.

+1

В примере кода, который вы указываете, '' 'будет доступно внутри' A'; может возникнуть ситуация, когда вы захотите сделать что-то подобное. Однако этот вопрос кажется слишком широким; это полностью зависит от обстоятельств, и я не думаю, что есть быстрый ответ вроде «ну, в таких-то случаях вы хотите использовать внутреннюю собственность внутри частного класса» – Filkolev

+1

@Fikolev Я не согласен. В приведенном выше случае внутренние и общедоступные будут идентичны, поэтому причина, по которой я поставил вопрос, - это когда будет время использовать внутреннее и общедоступное в приведенном выше сценарии. – Maxqueue

+1

@Filkolev Пример. Если вы попытались создать общедоступный метод внутри 'A', который возвращает экземпляр' B', это даст ошибку компиляции о возврате класса более ограничительного доступа. Только код внутри 'A' должен быть способен что-либо сделать с помощью' B', и, конечно, код внутри 'A' находится в текущей сборке, поэтому ... – Katana314

ответ

1

Я так не считаю. В C# частичные классы не могут охватывать сборки, поэтому я не вижу случая, когда другое определение типа в той же сборке может иметь различный доступ к s, чем определение типа в чужой сборке. Внутренний - модификатор доступности, применяемый только на уровне сборки, поэтому в данном случае я думаю, что internal функционально эквивалентен public. Однако я был бы рад, если бы мне показалось, что он ошибается.

+0

Согласен, я не мог думать о сценарии, где это применимо. – Maxqueue

1

Для компилятора это не имеет значения. Тем не менее, для кого-то, кто читает или реорганизует ваш код, это показывает ваше намерение.

Если свойство действительно представляет собой деталь сборки, вы можете сохранить его внутренним. Таким образом, когда кому-то нужно сделать сообщение class B по какой-то причине, ему не нужно будет думать, должно ли это свойство быть видимым или не документировать его. Кроме того, он не будет случайно покидать общественность, если она предназначена для скрытия.

Вы можете подумать как «Каким будет модификатор доступа, если этот класс был общедоступным?»

+0

Мне нравится ваш ответ, однако я чувствую, что если бы цель состояла в том, чтобы класс был закрытым, то целью этого класса было НЕ быть открытым, и он должен создать соответствующий модификатор доступа для того, как он должен быть сейчас. При рефакторинге разработчик должен решить, для чего нужно изменить модификаторы доступа. – Maxqueue

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