Соглашение о присвоении имен набора.NET
Тривиальное решение было бы:
using System.Collections.Generic;
...
public static Dictionary<TKey, TValue>
Merge<TKey,TValue>(IEnumerable<Dictionary<TKey, TValue>> dictionaries)
{
var result = new Dictionary<TKey, TValue>();
foreach (var dict in dictionaries)
foreach (var x in dict)
result[x.Key] = x.Value;
return result;
}
4 ответа
Я бы сказал, что с универсальными шаблонами редко когда возникает причина для создания настраиваемого типа коллекции. Но если вы должны, я бы сказал, что ProductCollection лучше всего соответствует соглашениям об именах фреймворка.
Тем не менее, рассмотрите возможность использования List или Collection или еще лучше IList или ICollection .
Edit: Это ответ на комментарии MrEdmundo ниже.
В вашем случае у вас есть два варианта. Самым очевидным выбором было бы использовать наследование следующим образом:
class Ball { }
class BallCollection : List<Ball>
{
public String Color { get; set; }
public String Material { get; set; }
}
Я говорю очевидное, потому что кажется на первый взгляд лучшей идеей, но после небольшого размышления становится ясно, что это не лучший выбор . Что, если вы или Microsoft создаете новый SuperAwesomeList и хотите использовать его для повышения производительности своего класса BallCollection ? Это будет сложно, потому что вы привязаны к классу List через наследование, и изменение базового класса потенциально может нарушить работу любого кода, который использует BallCollection как List .
Итак, какое решение лучше? Я бы порекомендовал вам в этом случае отдать предпочтение композиции наследованию. Итак, как будет выглядеть решение на основе композиции?
class Ball { }
class BallCollection
{
public String Color { get; set; }
public String Material { get; set; }
public IList<Ball> Balls { get; set; }
}
Обратите внимание, что я объявил свойство Balls как имеющее тип IList . Это означает, что вы можете реализовать свойство, используя любой желаемый тип, если этот тип реализует IList . Это означает, что вы можете свободно использовать SuperAwesomeList в любой момент, что делает этот тип значительно более масштабируемым и менее болезненным в обслуживании.
Товары , конечно, не правильно ИМХО. Нестатическое имя класса должно представлять существительное (не во множественном числе), потому что вы должны иметь возможность сказать « x is a [classname] ».
Очевидно, что Products не не вписывается в эту схему. ProductCollection делает:
Иллюстрация:
var products = new Products(); // products is a Products
var products = new ProductCollection(); // products is a ProductCollection
Какой из них «звучит правильно»?
Еще кое-что об именах классов коллекций: я обычно стараюсь называть классы коллекций таким образом, чтобы было понятно, какие коллекции это есть.
Например:
- класс ProductCollection : можно только перечислить и получить счетчик (т.е. реализует только интерфейс (ы) ICollection)
- класс ProductList : список которым можно управлять с помощью Add (), Insert () и т. Д. (Т.е. реализует интерфейс (ы) IList)
- class ProductDictionary : словарь продуктов, доступных по некоторому ключу (т.е. реализует интерфейс (ы) IDictionary)
Последний может быть неоднозначным, если могут возникнуть сомнения в том, какой ключ в словаре, поэтому лучше указать тип ключа (например, ProductDictionaryByString). Но, честно говоря, я редко называю это так, потому что в большинстве случаев ключ все равно будет строкой.
.NET Framework часто использует постфикс «Коллекция» для своих типов коллекций. StringCollection, ObservableCollection, KeyedCollection и т. Д. Итак, выбирайте ProductCollection.
Noticed nobody answered you on the retVal stuff (Or I could just be getting blind). Although I'm not an expert; on the matter of the retVal issue I'm not 100% sure what you mean by "naming of return variable", but if you mean stuff like this:
public void GetSomething(out object retVal)
{
retVal = ThingFactory.CreateSomething();
}
I would say, no matter what the convention is, don't do it. It's very annoying. Just return the value instead. If you need to return more than one thing, then I would think the method either does more than one thing (which a method shouldn't) or those things should be wrapped up in some sort of logical class that could be returned instead.
If instead by "naming of return variable" you mean stuff like this:
var retVal = ThingFactory.CreateSomething();
Then I would say name the variable according to what it is. What it is going to be used for. If its a list of cars, call it listOfCars, if it's a piece of bread to be eaten later, call it pieceOfBread or pieceOfBreadToBeEatenLater.
Hope that helped and that it wasn't too far off into a field somewhere :p