Должен ли я использовать внутреннюю или общедоступную видимость по умолчанию?

Ответ 1

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

С этой целью дайте мне только те функциональные возможности, которые должен выполнять класс для работы.

Рассмотрим лифт. Чтобы заставить его пойти на пол, я нажимаю кнопку. Это открытый интерфейс к черному ящику, который активирует все функции, необходимые для подъема лифта на желаемый этаж.

Ответ 2

То, что вы сделали, именно то, что вы должны делать; дать вашим классам минимальную видимость. Если вы хотите по-настоящему разойтись, вы можете сделать все internal (самое большее) и использовать атрибут InternalsVisibleTo, так что вы можете отделить свою функциональность, но все же не выставлять ее в неизвестный внешний мир.

Единственная причина публиковать вещи в том, что вы упаковываете свой проект в несколько DLL и/или EXE и (по какой-либо причине), вы не хотите использовать InternalsVisibleTo, или вы создаете библиотеку для использование третьими лицами. Но даже в библиотеке для использования третьими сторонами вы должны попытаться уменьшить "площадь поверхности", где это возможно; чем больше у вас классов, тем более запутанной будет ваша библиотека.

В С# один хороший способ убедиться, что вы используете минимальную видимость, - это оставить модификаторы видимости до тех пор, пока они вам не понадобятся. Все в С# по умолчанию имеет минимальную видимость: внутреннее для классов и личное для членов класса и внутренних классов.

Ответ 3

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

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

Ответ 4

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

Вместо того, чтобы маркировать класс как internal, я оставляю доступность пустой. Таким образом, public выделяется как нечто заметное. (Исключением, конечно же, являются вложенные классы, которые должны быть отмечены, если они должны быть видимыми даже в одной и той же сборке.)

Ответ 5

Большинство классов должны быть internal, но большинство нечастных членов должны быть public.

Вопрос, который вы должны задать о члене, - "если класс был создан public, я хочу, чтобы член был открыт?". Ответ обычно "да" (так public) ", потому что классы без каких-либо доступных членов не очень полезны! Члены internal имеют определенную роль; они "доступ на задворках" означают только для близких родственников, которые живут в одной и той же сборке.

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

Ответ 6

Вы должны стремиться как можно меньше подвергать себя другим классам, и тщательно подумать о том, что вы делаете, и почему.

Ответ 7

Есть ли причина, по которой вам нужно использовать Internal вместо Private? Вы понимаете, что Internal имеет область уровня сборки. Другими словами, внутренние классы/члены доступны для всех классов в сборке нескольких классов.

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

Ответ 8

Я нашел проблему с использованием внутренних классов насколько это возможно. Вы не можете иметь методы, свойства, поля и т.д. Этого типа (или тип параметра или тип возврата), более видимые, чем внутренние. Это приводит к созданию конструкторов, которые являются внутренними, а также свойствами. Это не должно быть проблемой, но, по сути, при использовании Visual Studio и дизайнера xaml возникают проблемы. Ложноположительные ошибки обнаруживаются конструктором из-за того, что методы не являются общедоступными, свойства пользовательского управления, как представляется, не видны дизайнеру. Я не знаю, поделились ли другие с такими проблемами...

Ответ 9

Вы должны попытаться сделать их максимально видимыми, но, как указано Майком выше, это вызывает проблемы с UserControls и использует VS Designer с этими элементами управления в формах или других UserControls.

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

Недавно у меня возникла проблема, когда разработчик продолжал удалять строку this.myControl = new MyControl() из метода InitializeComponent(), потому что UserControl MyControl был помечен как внутренний вместе со своим конструктором.

Это действительно ошибка, о которой я думаю, потому что, даже если они помечены как внутренние, они все еще отображаются в Toolbox для добавления в Designer, либо Microsoft должна показывать только публичные элементы управления с помощью публичных конструкторов, либо им нужно заставить работать внутренние элементы управления.

Ответ 10

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

Ответ 11

Не выбирайте "выбор по умолчанию", который наилучшим образом соответствует потребностям видимости для данного класса. Когда вы выбираете новый класс в Visual Studio, шаблон создается как:

class Class1
{
}

Что является приватным (поскольку область не указана). Вам решать указать область для класса (или оставить как конфиденциальную). Должна быть причина для раскрытия класса.

Ответ 12

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

Я покажу что-то видимое по этой цепочке на публике, только когда есть веские причины.

Ответ 13

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

Сегодня мне приходилось использовать рефлексию, чтобы добраться до внутренних систем System.Data.DataTable(мне нужно построить динамически быстро, без всех проверок), и мне пришлось использовать отражение, так как не мне был доступен один тип; все они были обозначены как внутренние.

Ответ 14

по умолчанию класс создается как внутренний в С#:  внутренние средства: доступ ограничен текущей сборкой.

см http://msdn.microsoft.com/en-us/library/0b0thckt.aspx

Хорошая статья. Область по умолчанию - внутренняя: http://www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-a-C-Sharp-class/