Повторное использование кода C# через пространства имен

Question

Мне нравится создавать файл, полный пользовательских функций, которые я создал, которые я могу использовать в другом проекте или что-то в этом роде. Теперь я не совсем понимаю, как это сделать, как правило, на языке, таком как php, вы просто создаете файл php, а затем включаете include («cust_lib.php») или независимо от того, какой файл вызывается.

Теперь я думаю, что процесс включает библиотеку, имеющую собственное пространство имен, либо либо использовать custom_lib; или custom_lib :: внутри скрипта (я не хочу вдаваться в дискуссию о том, какой из них лучше всего подходит).

Это право? Или мне нужно создать библиотеку и преобразовать ее в DLL, если да, то как это сделать, какой синтаксис имеет dll внутри и т. Д.

Однако, если его справедливый файл в одном проекте, Мне нужно идти по этому маршруту? Я могу просто создать пространство имен и использовать это?

Это то, что я работаю в данный момент, и думал, что это будет что-то вроде этого

namespace Custom_Lib{ 
    ~~functions to go here~~ 
} 

Однако функции должны существовать в пределах класса не так ли? Так что становится чем-то вроде

namespace Custom_Lib{ 
    class custom_lib{ 

    public string function1(string input){ 
     return input; 
    } 

    } 
} 

Таким образом, некоторые справки, указатели, примеры будут оценены, так что я могу обернуть мою голову вокруг этого

Спасибо, Psy.

(Да, я называю их функции, что просто приходит из длинного PHP/JS и т.д. фоне)

Answer 1

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

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

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

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

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

Что касается проблем синтаксиса: да все методы должны существовать внутри класса.Однако, если класс просто контейнер из способов, вы можете сделать это (и методы static):

public static class CustomLib 
{ 
    public static string GetSomethingInteresting(int input) 
    { 
     // your code here... 
    } 
} 

Таким образом, вам не нужно будет создать экземпляр CustomLib, но может просто вызвать метод :

Answer 2

Здесь нет вопросов. Вы ответили сами. Да, вы должны построить класс для включения всех вспомогательных методов. И да, вы можете либо скомпилировать его в dll, если хотите повторно использовать его в нескольких проектах, либо просто добавить исходный файл в проект.

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

Answer 3

В дополнение к Fredrik MORK в хорошо написанной и безошибочный ответ, я бы добавить это:

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

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

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