Как Вы организуете код C# в в файлы?
Я нашел больше всего, если не все эти ответы полагаются на базовый класс (Object), чтобы реализовать сопоставимые или иметь вспомогательный сопоставимый интерфейс.
Не с моим решением! Следующий код позволяет сравнить поле объекта, зная его имя строки. Вы можете легко изменить его, чтобы не использовать имя, но тогда вам нужно его выставить или создать один из объектов, которые вы хотите сравнить.
Collections.sort(anArrayListOfSomeObjectPerhapsUsersOrSomething, new ReflectiveComparator(). new ListComparator("name"));
public class ReflectiveComparator {
public class FieldComparator implements Comparator<Object> {
private String fieldName;
public FieldComparator(String fieldName){
this.fieldName = fieldName;
}
@SuppressWarnings({ "unchecked", "rawtypes" })
@Override
public int compare(Object object1, Object object2) {
try {
Field field = object1.getClass().getDeclaredField(fieldName);
field.setAccessible(true);
Comparable object1FieldValue = (Comparable) field.get(object1);
Comparable object2FieldValue = (Comparable) field.get(object2);
return object1FieldValue.compareTo(object2FieldValue);
}catch (Exception e){}
return 0;
}
}
public class ListComparator implements Comparator<Object> {
private String fieldName;
public ListComparator(String fieldName) {
this.fieldName = fieldName;
}
@SuppressWarnings({ "unchecked", "rawtypes" })
@Override
public int compare(Object object1, Object object2) {
try {
Field field = object1.getClass().getDeclaredField(fieldName);
field.setAccessible(true);
Comparable o1FieldValue = (Comparable) field.get(object1);
Comparable o2FieldValue = (Comparable) field.get(object2);
if (o1FieldValue == null){ return -1;}
if (o2FieldValue == null){ return 1;}
return o1FieldValue.compareTo(o2FieldValue);
} catch (NoSuchFieldException e) {
throw new IllegalStateException("Field doesn't exist", e);
} catch (IllegalAccessException e) {
throw new IllegalStateException("Field inaccessible", e);
}
}
}
}
8 ответов
Независимо от того, что Вы делаете, просто делайте это последовательно. Я не полагаю, что существует любой единственный ответ (хотя существует несколько неправильных). Но просто удостоверьтесь, что Вы остаетесь верными своей форме, поскольку это будет ключом для Вашего преемника (преемников) для нахождения вещей легко.
В настоящее время я делаю:
- Один блок для производственного кода + модульные тесты
- структура каталогов подражает пространствам имен
- , один тип на вложенные типы файла
- получает их собственный файл, с помощью
partialтипы. Это:
- получает их собственный файл, с помощью
// ------ C.cs
public partial class C : IFoo
{
// ...
}
// ------ C.Nested.cs
partial class C
{
public class Nested
{
// ...
}
}
Я делаю это вполне так же. Одна точка, где я отличаюсь:
- один тип на файл
я объявляю типы делегата, где мне нужны они, т.е. не в их собственном файле, а скорее в классе, который использует их.
Я создаю один блок на архитектурный слой. (WinUI.exe, BusinessWorkflow.dll, BusinessComponent.dll и т.д.
Затем один физический файл в классе.
, Таким образом, это "вертикально".
Пространства имен, концептуально, идут горизонтально, собирая в группу доменную функциональность уровня. Весь клиентский материал входит в "Клиентское" пространство имен, скажем, Заказы входят "в Учет. AccountsPayable", например.
Как каждый блок только ссылаются на тот под ним в - архитектурно, Ваш intellisense ограничивается приятно соответствующими ссылками в Вашей модели предметной области.
(Должны согласиться с вышеупомянутым, хотя - непротиворечивость жизненно важна.
Неважно, насколько маленький тип, поместите каждый тип в отдельный файл - Исключение: вложенные классы и делегаты
Между прочим, с помощью частичного класса для разделения для единственной цели поместить вложенный тип в его собственный файл походят на излишество. Частичные классы должны использоваться рассудительно и обычно использоваться для инструментов поколения файла - необходимо рассмотреть, как "назвать" частичные классы для вложенных классов. Придумывание интуитивного названия физического вложенного файла может быть утомительным, и это - определенно не простая задача.
Для проектов, назовите свои проекты отразить пространства имен - Исключение: Когда вложенное пространство имен становится большим, я переместил бы вложенную папку в другой проект.
Для крошечных проектов меньше чем с дюжиной классов, всего один класс на файл.
Для проектов предприятия, у меня есть несколько проектов в решении. Они сгруппированы целью (бизнес-классы, интерфейсы, UI). Каждый класс имеет свой собственный файл.
Я предпочитаю стандартный one-file-per-public-class с папками в проекте (которые отображаются на подкаталоги), раньше группировал концептуально связанные классы по мере необходимости для хранения представления Solution Explorer управляемым. Если Ваши имена классов хорошо выбраны, папки не должны быть строго необходимыми, но они полезны, если проект имеет много классов.
Используя отдельные файлы для вложенных типов походит на излишество, по крайней мере, если вложенные классы являются относительно простыми классами 'помощника', и особенно поэтому, если они являются частными.
основное практическое возражение Вашему другу "все в одном огромном файле" схема - то, что Visual Studio имеет тенденцию становиться очень, очень медленной, когда это пытается иметь дело с очень длинными файлами кода.
Я предпочитаю этот вид организации на любом языке.
Связанные маленькие классы в их собственном файле (файлах).
Большие классы в их собственном файле.
Каталоги для отдельных подпроектов.