【问题标题】:c# string constants vs static properiesc# 字符串常量 vs 静态属性
【发布时间】:2018-06-08 14:23:39
【问题描述】:

我有一个带有预定义常量字符串的类,这些字符串用作键,通过提供的键从外部存储中检索数据。

public class StorageKeys
{
    public const string SomeKey = "Foo";
    public const string AnotherKey = "Foooo";        
}

public interface IStorage
{
    string GetValue(string key);
}

这样使用:

IStorage t = new Storage();
string value = t.GetValue(StorageKeys.SomeKey);

它有效,但我担心有可能只使用字符串参数调用GetValue 方法,这可能会导致错误:

string value = t.GetValue("Illegal key");

这就是我想出这个想法的原因:

public class StorageKeys
{
    public static StorageKeys SomeKey = new StorageKeys("Foo");
    public static StorageKeys AnotherKey = new StorageKeys("Foooo");

    private StorageKeys(string key)
    {
        _key = key;
    }

    private readonly string _key;

    public static implicit operator string(StorageKeys key) => key._key;
}

public interface IStorage
{
    string GetValue(StorageKeys key);
}

在这些更改之后,我的方法只能与正确的键一起使用,但我认为由于静态属性和隐式转换,它会降低性能。

所以我的问题是一个好主意吗?

我是不是太担心了?

与第一种方法相比,我的第二种方法会慢多少?

还有其他方法可以防止传递错误的参数吗?

【问题讨论】:

  • 那么你为什么要关心有人用无效的键调用方法呢?这是他们要处理的问题。只要给他们一个异常。
  • 如果您非常关心正确的密钥,请封装接口并提供GetFooGetFoooo 方法。
  • "我的第二种方法比第一种慢多少?"为什么要问我们,而不是衡量自己?无论如何,我怀疑它会产生巨大的影响——如果有的话。 只需选择适合您的方法,除非您对该解决方案有特定问题。所以我想这个问题是相当基于意见的。
  • 你可能已经在这个问题上浪费了更多的时间,而不是通过选择上面提供的选项之一来节省你的应用程序所节省的时间:)
  • 没有速度差异,JIT编译器让差异消失。然而,存在很大的功能差异,公共 const 声明非常危险。当您提供一个也更改 const 值的错误修复时,您会遇到麻烦。这些更改不会影响使用这些值的任何其他程序集,const 值是在编译时加入的。公共 const 仅适用于“清单常量”,其值永远不会再次改变。 .NET Framework 只有几个,Math.Pi 就是其中之一。

标签: c# performance constants


【解决方案1】:

我是不是太担心了?

简短的回答,是的。

你想要做的是防止传递一个你不应该做的无效参数,你应该考虑使用一个可能的枚举 IF,这使得它 99.9% 类型安全并且几乎没有需要进行检查。

在您需要该参数为字符串的情况下,只需在 GetValue(string key) 中执行验证,如果您希望稍后处理,则返回 null 或仅抛出异常。

【讨论】:

  • 正如我在 cmets 中指出的那样,使用枚举并不能让您免于执行验证检查。允许枚举采用基础类型的所有可能值,无论枚举是否具有具有该值的命名成员。
  • 你说得对,但唯一的办法就是故意将其转换为那种类型,例如:(StorageKeys)1
  • 所以,也许,您关于使用 one 将是“100% 类型安全”且不需要检查的说法并不完全正确?
  • 你去 :)
  • 99.9% 仍然意味着它不太可能发生,但您确实不需要显式强制转换来获取枚举值。通常通过一些 HTTP API 可能有反射代码,或者可能是很常见的 JSON/XML 反序列化。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-04-07
  • 1970-01-01
  • 2012-11-11
  • 1970-01-01
  • 2010-11-30
相关资源
最近更新 更多