Кто-либо может дать мне ДЕЙСТВИТЕЛЬНО серьезное основание использовать имена типов CLR вместо имен типов C# (псевдонимы) в коде (как общая практика)? [закрытый]
Я не знаю, возможно ли иметь значение по умолчанию в ConfigurationElementCollection. (у него не было свойства для значения по умолчанию).
Я полагаю, вы должны реализовать это самостоятельно. Посмотрите на пример ниже.
public class Repository : ConfigurationElement
{
[ConfigurationProperty("key", IsRequired = true)]
public string Key
{
get { return (string)this["key"]; }
}
[ConfigurationProperty("value", IsRequired = true)]
public string Value
{
get { return (string)this["value"]; }
}
}
public class RepositoryCollection : ConfigurationElementCollection
{
protected override ConfigurationElement CreateNewElement()
{
return new Repository();
}
protected override object GetElementKey(ConfigurationElement element)
{
return (element as Repository).Key;
}
public Repository this[int index]
{
get { return base.BaseGet(index) as Repository; }
}
public new Repository this[string key]
{
get { return base.BaseGet(key) as Repository; }
}
}
public class MyConfig : ConfigurationSection
{
[ConfigurationProperty("currentRepository", IsRequired = true)]
private string InternalCurrentRepository
{
get { return (string)this["currentRepository"]; }
}
[ConfigurationProperty("repositories", IsRequired = true)]
private RepositoryCollection InternalRepositories
{
get { return this["repositories"] as RepositoryCollection; }
}
}
Вот XML-конфигурация:
<myConfig currentRepository="SQL2008">
<repositories>
<add key="SQL2008" value="abc"/>
<add key="Oracle" value="xyz"/>
</repositories>
</myConfig>
И затем, используя свой код, вы получаете доступ к элементу по умолчанию, используя следующее:
MyConfig conf = (MyConfig)ConfigurationManager.GetSection("myConfig");
string myValue = conf.Repositories[conf.CurrentRepository].Value;
Конечно, MyConfig Класс может скрыть детали доступа к свойствам Repositories и CurrentRepository. У вас может быть свойство DefaultRepository (типа Repository) в классе MyConfig, чтобы вернуть это.
8 ответов
В актуальном коде? Нет, если только у вас не будет много людей, работающих над кодом, знакомых с .NET, но не знакомых с C #.
В именах членов? Абсолютно. Например, предположим, что Convert.ToSingle был вызван Convert.ToFloat - это полностью сбивает с толку разработчиков F #, для которых « float » означает «64 бит с плавающей точкой ».
Мое общее правило - псевдонимы C # для реализации, типы CLR для имен членов.
Если вы хотите найти аргументы в пользу использования имен типов CLR повсюду, Джефф Рихтер рекомендует, чтобы в« CLR через C # ". (Если у вас ее еще нет, купите копию независимо от этого - это замечательная книга.) Я не согласен с его аргументами, но они есть,
Обычно я использую псевдоним C # при объявлении переменной, но типы CLR для статических членов. Думаю, мне просто нравится то визуальное различие, которое он обеспечивает.
Я думаю, что почти единственный раз, когда имеет смысл всегда использовать имена типов CLR, приходится на многоязычный магазин. Еще одна возможность - если вы планируете в ближайшем будущем переключиться с текущего языка на другой. В этом случае я бы выбрал имена типов CLR.
Кроме этого, на самом деле нет веской мотивации выбирать одну методологию перед другой. Гораздо важнее, так или иначе, прийти к консенсусу и убедиться, что все следуют «стандарту».
В этом случае я бы выбрал имена типов CLR.Кроме этого, на самом деле нет веской мотивации выбирать одну методологию перед другой. Гораздо важнее, так или иначе, прийти к консенсусу и убедиться, что все следуют «стандарту».
В этом случае я бы выбрал имена типов CLR.Кроме этого, на самом деле нет веской мотивации выбирать одну методологию перед другой. Гораздо важнее, так или иначе, прийти к консенсусу и убедиться, что все следуют «стандарту».
Моя предыдущая группа разработчиков приняла эту практику из-за сочетания разработчиков C # и Visual Basic.NET. Было решено, что типы CLR упростят общение между людьми, использующими C # и VB.NET.
Объекты Python хранят свои переменные экземпляра в словаре, который принадлежит объекту. vars (x) возвращает этот словарь (как и x .__ dict __ ). dir (x) , с другой стороны, возвращает словарь x «атрибутов, атрибутов своего класса и рекурсивно атрибутов базовых классов своего класса»
. Когда вы обращаетесь к атрибуту объекта с помощью оператора точки, python делает гораздо больше, чем просто ищет атрибут в словаре этого объекта. Обычный случай - когда x является объектом класса C , и вы вызываете для него метод m .
class C(object):
def m(self):
print "m"
x = C()
x.m()
Метод m ] не хранится в x .__ dict __ . Это атрибут класса C .
Когда вы вызываете xm () , python начнет с поиска m в x .__ dict __ , но не найдет его. Однако он знает, что x является экземпляром C , поэтому в следующий раз он будет искать в C .__ dict __ , находить его там и вызывать m с x в качестве первого аргумента.
Итак, разница между vars (x) и dir (x) состоит в том, что dir (x) выполняет дополнительную работу по поиску в классе x (и его базах) атрибутов, доступных из него, а не только тех атрибутов, которые хранятся в x ] собственная таблица символов. В приведенном выше примере vars (x) возвращает пустой словарь, поскольку x не имеет переменных экземпляра. Тем не мение,
Нет. Я не могу. Мне кажется, что псевдонимы тут нужны :)
Я думаю, что имеет смысл последовательно использовать имена типов CLR при вызове методов-членов статического типа, так как вы в любом случае должны делать это в перечислениях. Поэтому для объявления используйте имена типов C #, но при вызове статических членов используйте типы CLR. Это упрощает чтение и делает его более последовательным, imho. Так как вы не можете написать:
MyEnum value = enum.Parse(typeof(MyEnum), "value");
, что лучше подходит для:
int i = int.Parse("1");
long l = long.parse("1");
Вы бы предпочли написать:
int i = Int32.Parse("1");
long l = Int64.Parse("1");
MyEnum value = Enum.Parse(typeof(MyEnum), "value");