Определяя класс как внутренний, определяете ли вы, что обычно являются открытыми полями, как внутренние?

Question

Определяя класс как внутренний, определяете ли вы, что обычно являются открытыми полями, как внутренние? Или вы оставляете их как публичные? У меня есть набор классов с открытыми / закрытыми методами, которые я решил установить как внутренние. Теперь я должен изменить модификатор класса на внутренний и оставить остальные методы / свойства такими, какие они есть (публичные / частные) или переключить их на (внутренние / частные)?

Я не вижу особого смысла в изменении его на внутренний, и если по какой-то причине позже я захочу вернуть их в открытый доступ, потребуется много работы, чтобы снова их опубликовать. 1003 *

Есть еще мысли по этому поводу?

Answer 1

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

Answer 2

Если у меня есть внутренний класс, я оставляю его как общедоступный (или защищенный / приватный, если это так). Я нахожу, что часто у меня есть классы, которые, я надеюсь, я могу оставить для себя внутренними, и в конечном итоге мне приходится в конечном итоге выставлять их, а переключение всех соответствующих членов обратно на общедоступное раздражает.

Answer 3

Я думаю, что вы должны, как правило, предоставлять членам такую ​​же видимость, как если бы тип был сам по себе публичным.

То есть члены, являющиеся частью общедоступного API, должны быть общедоступными, а члены, являющиеся помощниками специального назначения, которые должны быть видимы только для "друзей" классов, должны быть внутренними.

Это означает, что не будет никаких изменений в видимости члена, если вы когда-нибудь решите сделать Тип общедоступным.

Что более важно, он также документирует ваше намерение - любой, кто читает ваш код, сможет определить, какие (если таковые имеются) участники предназначены для внутреннего использования.

Answer 4

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

Answer 5

Немного покопайтесь в Reflector, и вы увидите, что сам BCL в этом крайне противоречив. Вы увидите много внутренних классов с public членами и многие другие с internal членами. Несколько классов даже смешивают и сопоставляют два без какой-либо конкретной рифмы или причины, которую я могу различить.

Здесь нет «правильного» ответа, но есть несколько вещей, которые вы должны учитывать, когда вам нужно принять решение по этому вопросу:

• internal члены не могут неявно реализовывать интерфейс, а явные реализации всегда являются закрытыми. Поэтому, если вы хотите, чтобы члены интерфейса были доступны через экземпляр class (метод IDisposable для *1013* является обычным), они должны быть общедоступными.

• Тип видимости может меняться. В будущем вы можете решить, что класс internal обладает некоторыми полезными функциями, которые вы хотите сделать доступными извне. Но если вы это сделаете, то все открытые участники станут доступны для каждого . Вам следует заранее решить, хотите ли вы этого.

• С другой стороны, еще одна причина, по которой вы можете создать internal класс public, заключается в том, что вы решаете, что вам нужно создать его подкласс, и что производные классы должны находиться в другой сборке. В этом случае некоторые из ваших internal членов, скорее всего, должны быть protected internal, иначе производные классы не будут иметь доступа к членам, которые им могут понадобиться.

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

1. То, что это не кажется полезным внешнему миру, но на самом деле не будет вредным . Типичным примером может быть служебный класс, который был запущен за 5 минут и не выполняет много проверки или проверки ошибок. В этом случае это нормально для кого-то, чтобы сделать его public, если они немного ужесточают код и / или документируют, как правильно его использовать. Сделайте это предположение явным, сделав членов public.

2. что на самом деле небезопасно для внешнего потребления; он может манипулировать каким-либо защищенным состоянием, оставлять дескрипторы или транзакции открытыми и т. д. В этом случае вы действительно хотите сделать отдельные методы internal, чтобы было абсолютно ясно, что никто другой не должен использовать этот класс, ever .

Выберите тот, который подходит для вашего сценария.

Answer 6

Мы используем внутреннее ключевое слово для членов во внутренних классах, так что цель ясна. Однако это не удастся, если неявно реализовать внутренние интерфейсы, где члены должны быть определены как публичные. Мы не знаем почему и считаем это случайной ошибкой в ​​спецификации языка, с которой нам приходится жить.