куда вставлять пример из вики?
Ты не поверишь, практически куда хочешь.))
Самый удобный, это вставить класс Example в пространство имен ZennoLab.OwnCode.
namespace ZennoLab.OwnCode
{
/// <summary>
/// A simple class of the common code
/// </summary>
public class CommonCode
{
/// <summary>
/// Lock this object to mark part of code for single thread execution
/// </summary>
public static object SyncObject = new object();
// Insert your code here
}
internal class Example
{
public static int Execute()
{
//...
}
}
}
Тогда чтобы вызвать метод Execute, в кубике сишарпа пишешь Example.Execute();
Полный путь ZennoLab.OwnCode.Example.Execute();
Или так, т.е. создаешь вложенный namespace.
namespace ZennoLab.OwnCode
{
/// <summary>
/// A simple class of the common code
/// </summary>
public class CommonCode
{
/// <summary>
/// Lock this object to mark part of code for single thread execution
/// </summary>
public static object SyncObject = new object();
// Insert your code here
}
namespace Sample
{
internal class Example
{
public static int Execute()
{
//...
}
}
}
}
Тогда чтобы вызвать метод Execute, в кубике сишарпа пишешь Sample.Example.Execute();
Полный путь ZennoLab.OwnCode.Sample.Example.Execute();
Но так обычно не делается. Точнее делается, но это разносится по разным файлам. В зенке этого не сделать. Т.е. Sample будет вложенным пространством имен для ZennoLab.OwnCode и в отдельном файле это будет выглядеть так.
namespace ZennoLab.OwnCode.Sample
{
internal class Example
{
public static int Execute()
{
//...
}
}
}
Зачем такие "вложенности", напишу ниже.
Ну и последний вариант. Два отдельных namespace.
namespace ZennoLab.OwnCode
{
/// <summary>
/// A simple class of the common code
/// </summary>
public class CommonCode
{
/// <summary>
/// Lock this object to mark part of code for single thread execution
/// </summary>
public static object SyncObject = new object();
// Insert your code here
}
}
namespace Sample
{
internal class Example
{
public static int Execute()
{
//...
}
}
}
Тогда чтобы вызвать метод Execute, в кубике сишарпа пишешь Sample.Example.Execute();
Полный путь Sample.Example.Execute();
Почему во втором и третьем одинаково - Sample.Example.Execute(); ?
Потому что во втором варианте зенка подхватывает ZennoLab.OwnCode и эту часть можно не писать.
В третьем же, над писать полный путь, или добавлять в using свой namespace, чтобы не писать его.
Тогда можно написать Example.Execute();
что значит класс - public class CommonCode , и нём есть закоментированная строчка - Insert your code here
Это "болванка" класса с одним статическим методом, вместо "Insert your code here" пишется свой код.
Класс CommonCode можно удалить, и написать свой.
так же написано, что все классы должны быть public , а в примере работы с табом (выше самый первый кусок кода) модификатор доступа internal , как понимать такую справку?
Ну вот и добрались до модификаторов доступа.
А также напишу зачем нужна вложенность namespace.
Аналогию буду проводить на пример компа, так думаю будет понятней.
Представим что есть комп, и в нем есть несколько винтов.
Комп - это программа, например зенка.
Винты - это сборки(dll), которые можно подключать/отключать.
На винте есть инфа, она расположена в различных папках и файлах.
Также и в сборке, namespace это "папки" в которых находятся классы.
Вложенность namespace делается для удобства, чтобы был порядок, а не все в кучу. Чтобы классы были тематически разбиты по разным namepsace.
C пониманием этого думаю проблем не должно быть.
Теперь по модификаторам доступа. Возьму только три
public,
private и
internal, про остальное можно почитать тут.
https://msdn.microsoft.com/ru-ru/library/ms173121.aspx
Остальные не беру а также не буду приводить различные комбинации, чтобы не забивать голову, чтобы было понятно.
Классы надо добавлять в namespace, модификатор доступа у таких классов не может быть private, он может быть или public или internal(что и есть по умолчание, если у класса не прописывать модификатор доступа).
Отличие public от internal в том, что если класс public, то он будет виден из другой сборки или основной программе.
Если по аналогии с компом, если файл public, то ее видно с другого винта или с компа, аналогия конечно кривоватая, но думаю понятно.
Если internal, то данным классом можно пользоваться только внутри сборки, т.е. допустим внутри сборки есть класс, который юзает какой то другой internal класс.
Основной программе или из другой сборки данный класс виден не будет.
Также класс можно добавить в другой класс.
class SomeClass
{
class InternaalClass
{
}
}
Если у InternaalClass задать модификатор доступа private, то к нему доступа извне не будет, им можно будет пользоваться только внутри класса SomeClass.
Если же InternalClass будет паблик, то им можно будет пользоваться и внутри сборки.
А также из другой сборки или основной программы, только если у родительского класса уровень доступа не будет internal.
Поэтом возвращаясь к вопросу
но в ней нет ни одного рабочего примера, так же написано, что все классы должны быть public , а в примере работы с табом (выше самый первый кусок кода) модификатор доступа internal , как понимать такую справку?
Без разницы какой будет модификатор, или public или internal.
На первый взгляд, кажется что полный жестяк.
Нахера напридумывали эти namespace и модификаторы доступа.
На самом деле все просто и логично, писать и читать дольше.
Надо только понять в чем прикол и зачем это.
Модификаторы доступа нужны для того, чтобы разграничить права, чтобы было доступно только то, что можно, а не все подряд. Грубо говоря чтобы нельзя было кривыми ручкам влезть туда, куда не надо.
Взять ту же зенку, есть основная прога и еще куча доп. либ.
Представим если бы не было разграничения по уровням доступа к различным классам зенки. Был бы доступ к классам, с помощью которых она работает, и которые обычному юзеру не нужны.
Тогда бы возникли очень интересные моменты, как минимум по неосторожности или намеренно можно бы было вызвать какой то метод, который бы мог повесить зенку.
А как максимум, можно бы было "порулить" зенкой, делая то на что разрабы вообще не рассчитывали.
Поэтому модификаторы доступа очень удобная и полезная штука, в идеале должно закрываться все, чтобы не было дырок, и разрешаться только самый необходимый минимум.
