Конвенция об установлении имен .NET Collection
Мой коллега и я обсуждали вопрос о том, какие коллекции следует называть.
Например:
Продукт класса - коллекция - продукты класса
или
Класс продукта - коллекция - класс ProductCollection
Я посмотрел вокруг, чтобы увидеть, могу ли я видеть какие-либо рекомендации или причины для использования одного или другого, но ничего не кажется spring. Предполагается, что структура использует оба варианта, например. Аргумент, который я вижу, состоит в том, что класс, имеющий набор переменных продуктов, должен называться Products, но должен иметь тип ProductCollection.
Что является правильным, если оно есть?
В том же флюгере есть стандарт для обозначения возвращаемой переменной для функции. например RetVal?
В основном мы кодируем С#, хотя я не уверен, что затрагивает мой вопрос.
Ответы
Ответ 1
Я бы сказал, что с помощью дженериков редко бывает причина создавать собственный тип коллекции. Но если вы должны сказать, что ProductCollection
лучше всего соответствует соглашениям об именах в структуре.
По-прежнему используйте List<Product>
или Collection<Product>
или еще лучше IList<Product>
или ICollection<Product>
.
Изменить: Это ответ на комментарии MrEdmundo ниже.
В вашем случае у вас есть два варианта. Наиболее очевидным выбором было бы использовать наследование следующим образом:
class Ball { }
class BallCollection : List<Ball>
{
public String Color { get; set; }
public String Material { get; set; }
}
Я говорю очевидное, потому что на первый взгляд кажется лучшей идеей, но после некоторого раздумья становится ясно, что это не лучший выбор. Что делать, если вы или Microsoft создаете новый SuperAwesomeList<T>
и хотите использовать его для повышения производительности вашего класса BallCollection
? Это было бы сложно, потому что вы привязаны к классу List<T>
через наследование, а изменение базового класса потенциально может нарушить любой код, который использует BallCollection
как List<T>
.
Итак, какое лучшее решение? Я бы рекомендовал, чтобы в этом случае вам было бы лучше подарить композицию по наследству. Итак, каково будет решение на основе композиций?
class Ball { }
class BallCollection
{
public String Color { get; set; }
public String Material { get; set; }
public IList<Ball> Balls { get; set; }
}
Обратите внимание, что я объявил свойство Balls
имеющим тип IList<T>
. Это означает, что вы можете свободно реализовать свойство, используя любой тип, который вам нужен, если этот тип реализует IList<T>
. Это означает, что вы можете свободно использовать SuperAwesomeList<T>
в любой точке, что делает этот тип значительно более масштабируемым и гораздо менее болезненным для поддержки.
Ответ 2
Продукты, конечно, не соответствуют IMHO. Нестатическое имя класса должно представлять собой существительное (не множественное число), поскольку вы должны иметь возможность сказать: "x - это [имя_файла]".
Очевидно, Продукты не вписываются в эту схему. ProductCollection делает:
Иллюстрация:
var products = new Products(); // products is a Products
var products = new ProductCollection(); // products is a ProductCollection
Какой из них "звучит правильно"?
Другое дело в том, чтобы именовать классы коллекции: обычно я пытаюсь назвать классы коллекции таким образом, чтобы было ясно, какая именно коллекция.
Например:
- класс ProductCollection: может быть только перечислит и подсчитан граф (т.е. реализует только интерфейс ICollection)
- class ProductList: список, с которым можно манипулировать с помощью Add(), Insert() и т.д. (то есть реализует интерфейсы IList).
- класс ProductDictionary: словарь продуктов, доступных некоторым ключом (то есть реализует интерфейс IDictionary)
Последнее может быть неоднозначным, если может быть сомнение в том, что такое ключ словаря, поэтому лучше указать тип ключа (например, ProductDictionaryByString). Но, честно говоря, я редко называю это так, потому что в большинстве случаев ключ будет нитью.
Ответ 3
.NET Framework часто использует постфикс "Коллекция" для своих типов коллекций. StringCollection, ObservableCollection, KeyedCollection и т.д. Так что идите с ProductCollection.
Ответ 4
Заметили, что никто не ответил вам на материал retVal (или я просто могу ослепнуть). Хотя я не эксперт; по вопросу retVal
я не уверен на 100%, что вы подразумеваете под "именованием возвращаемой переменной", но если вы имеете в виду такие вещи:
public void GetSomething(out object retVal)
{
retVal = ThingFactory.CreateSomething();
}
Я бы сказал, независимо от того, что такое конвенция, не делайте этого. Это очень раздражает. Просто верните значение вместо этого. Если вам нужно вернуть несколько вещей, я бы подумал, что этот метод либо делает больше одного (который не должен), либо те вещи должны быть завернуты в какой-то логический класс, который может быть возвращен вместо этого.
Если вместо "именования возвращаемой переменной" вы имеете в виду такие вещи:
var retVal = ThingFactory.CreateSomething();
Тогда я бы назвал эту переменную в соответствии с тем, что она есть. Для чего он будет использоваться. Если это список автомобилей, назовите его listOfCars
, если это кусок хлеба, который нужно съесть позже, назовите его pieceOfBread
или pieceOfBreadToBeEatenLater
.
Надеюсь, что это помогло и что он не был слишком далеко в поле где-то: p
Ответ 5
Thesaurus.com
Не смотрите дальше. Больше вы не будете размышлять над плюрализованной сингулярностью. Просто закрепите одно из этих множественных защитных устройств на свое имя объекта:
- Ералаш
- Капля
- Trove
- Miscellany
- Vocab
- Load
- Агломерация
- курган
- Серия
- Lexicon
- Muster
- Глоссарий
- Клад
- Swarm
- Группа
- Cluster
- Convoy
- Сборки
- Табун
- Mob
- Batch
- Amassment
- ворса
- Банк
- Конгрегация
- Clump
- Volume
- Set
- Резерв
- Подборка
- Flock
- Армия
Сделайте это весело.