1
108
这是我们设计C 4的方法。 首先,我们列出了我们可以考虑添加到语言中的每一个可能的特性。 然后,我们将这些特性分成“这是坏的,我们绝不能这样做”、“这是棒的,我们必须这样做”和“这是好的,但这次我们不要这样做”。 然后我们研究了我们必须设计、实现、测试、记录、发送和维护“必须拥有”特性的预算,发现我们超出了预算的100%。 所以我们把一堆东西从“必须拥有”桶移到了“美好拥有”桶。 索引属性从未出现在任何位置 近的 “必须拥有”列表的顶部。他们在“好”名单上的排名很低,还和“坏主意”名单调情。 我们花在设计、实现、测试、记录或维护好的特性X上的每一分钟都是我们不能花在令人敬畏的特性A、B、C、D、E、F和G上的一分钟。我们必须无情地确定优先级,这样我们才能做到最好的特性。索引属性是不错的,但是nice还不足以真正实现。 |
2
19
C语言索引器
是
索引属性。它被命名
我不知道为什么,具体来说,它是这样设计的,但它似乎是一个有意的限制。但是,它与框架设计准则一致,框架设计准则确实建议使用非索引属性为成员集合返回可索引对象的方法。也就是说,“可索引”是一种类型的特征;如果它以多种方式可索引,那么它真的应该分为几个类型。 |
3
14
因为您已经可以这样做了,而且它迫使您考虑OO方面的问题,添加索引属性只会给语言增加更多的噪声。还有另一种方法。
我个人更希望看到的只是一种做事的方式,而不是10种方式。当然,这是一个主观的观点。 |
4
7
我以前喜欢索引属性的概念,但后来意识到它会增加可怕的模糊性,实际上 使不积极 功能。索引属性意味着您没有子集合实例。这是好是坏。实现起来比较容易,并且不需要返回到封闭的所有者类的引用。但这也意味着您不能将该子集合传递给任何对象;您可能需要每次枚举一次。你也不能在上面做前臂。最糟糕的是,从索引属性看不出它是索引属性还是集合属性。 这个想法是理性的,但它只会导致僵化和突然的尴尬。 |
5
5
我发现缺乏索引属性在试图编写干净、简洁的代码时非常令人沮丧。索引属性的含义与提供已索引的类引用或提供单个方法的类引用的含义非常不同。我发现,提供对实现索引属性的内部对象的访问甚至被认为是可以接受的,这有点令人不安,因为这通常会破坏对象方向的一个关键组件:封装。 我经常遇到这个问题,但今天我又遇到了这个问题,所以我将提供一个真实的代码示例。正在写入的接口和类存储应用程序配置,该配置是松散相关信息的集合。我需要添加已命名的脚本片段,并且使用未命名的类索引器可能意味着一个非常错误的上下文,因为脚本片段只是配置的一部分。 如果索引属性在C中可用,我可以实现以下代码(语法是将此[key]更改为propertyname[key])。
不幸的是,索引属性没有实现,所以我实现了一个类来存储它们,并提供了对它们的访问。这是不需要的实现,因为此域模型中配置类的目的是封装所有详细信息。此类的客户端将按名称访问特定的脚本片段,并且没有理由对其进行计数或枚举。 我本可以将其实现为:
这可能是我应该有的,但这是一个很有用的例子,说明为什么使用索引类来替换这个缺失的特性通常不是一个合理的替代品。 为了实现与索引属性类似的功能,我必须编写下面的代码,您会注意到,这段代码要长得多,更复杂,因此更难阅读、理解和维护。
|
6
2
另一个解决方法列在 Easy creation of properties that support indexing in C# ,这需要更少的工作。 编辑 :我还应该补充一点,作为对原始问题的回应,如果我们能够在库支持的情况下完成所需的语法,那么我认为需要一个非常强大的案例来将它直接添加到语言中,以便最小化语言膨胀。 |
7
1
嗯,我想说,他们没有添加它,因为它不值得设计、实现、测试和记录它的成本。 撇开开开开玩笑不说,这可能是因为解决方法很简单,而且该功能不会缩短时间和效益。不过,我不会惊讶地看到这似乎是一个改变。 您还忘记了提到,更简单的解决方法只是制定一个常规方法:
|
8
1
使用lambda代理索引功能有一个简单的通用解决方案 用于只读索引
用于可变索引
还有一个工厂
在我自己的代码中,我使用它就像
再举一个莫尼厄夫兰克特轮廓的例子
|
9
0
我也发现,您可以使用显式实现的接口来实现这一点,如下所示: Named indexed property in C#? (见回复中的第二种方式) |
jlandercy · PostgreSQL参数化窗口大小 7 年前 |