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

Question

Я довольно новый разработчик C# и .Net. Недавно я создал snapin MMC с использованием C# и был удовлетворен тем, насколько это было легко, особенно после прослушивания некоторыми ужасными историями некоторых других разработчиков моей организации о том, как трудно это сделать на C++.

В какой-то момент я в значительной степени прошел весь проект и сделал каждый экземпляр «общедоступного» ключевого слова «внутренним», за исключением случаев, когда требуется время выполнения, чтобы запустить snapin. Каково ваше отношение к этому, если вы вообще делаете классы и методы общедоступными или внутренними?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

class Class1 
{ 
} 

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

Answer 11

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

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

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

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

Answer 12

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

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

Answer 13

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

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

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

Answer 14

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

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

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