C＃（.NET）设计缺陷

一般而言，C＃或.NET Framework中最大的设计缺陷是什么？

示例：没有不可为空的字符串类型，从IDataReader提取值时必须检查DBNull。

我对此帖子表示强烈同意（对于那些缺乏ToString的人来说，有一个debugger属性可以为您的类提供自定义格式）。

在以上列表的顶部，我还将添加以下合理要求：

1. 非空引用类型作为对空值类型的补充，
2. 允许覆盖结构的空构造函数，
3. 允许通用类型约束指定密封类，
4. 我同意这里的另一个发帖人的要求，即在用作约束时，即要求任意构造函数签名。哪里T : new(string)哪里T : new(string, int)
5. 我也同意另一位关于修正事件的发帖人，无论是针对空事件列表还是在并发设置中（尽管后者很棘手）
6. 运算符应定义为扩展方法，而不应定义为类的静态方法（或至少不仅仅定义为静态方法），
7. 允许接口使用静态属性和方法（Java有此功能，但C＃没有），
8. 允许对象初始化程序中的事件初始化（当前仅允许使用字段和属性），
9. 为什么“对象初始化器”语法仅在创建对象时可用？为什么不随时提供它，即。var e = new Foo(); e { Bar = baz };
10. 修正二次枚举行为，
11. 所有集合都应具有用于迭代的不可变快照（即，对集合进行突变不应使迭代器无效），
12. 元组很容易添加，但是像“ Either<T>”这样的高效封闭式代数类型却不是，因此我很喜欢一种方法来声明封闭式代数类型并对其进行强制性模式匹配（基本上是对访问者模式的一流支持，但是效率更高）；因此，只需使用枚举，并通过详尽的模式匹配支持对其进行扩展，并且不允许出现无效的情况，
13. 通常，我希望支持模式匹配，但至少要支持对象类型测试。我也很喜欢另一篇文章中提出的switch语法，
14. 我同意另一篇文章，即System.IO像这样的类Stream在设计上有些差；需要一些实现的任何接口NotSupportedException都是不好的设计，
15. IList应该比它简单得多；实际上，对于许多具体的收集界面（例如ICollection，
16. 太多的方法引发异常，例如IDictionary
17. 我宁愿使用一种比Java更好的检查异常形式（有关如何做到这一点，请参见类型和效果系统的研究），
18. 修复通用方法重载解析中的各种烦人的极端情况；例如，尝试提供两种重载的扩展方法，一种对引用类型进行操作，另一种对可为空的结构类型进行操作，并查看您的类型推断如何，
19. 提供一种方法来安全地反映接口（如）的字段和成员名，这些接口INotifyPropertyChanged将字段名作为字符串；您可以使用扩展方法，该方法采用带有的lambda MemberExpression，即。() => Foo，但这不是很有效，
    • 更新：C＃6.0添加了nameof()用于单个成员名称的运算符，但是它不适用于泛型（nameof(T) == "T"而不是实际的类型参数名称：您仍然需要这样做typeof(T).Name））-也不允许您获取“路径”字符串，例如nameof(this.ComplexProperty.Value) == "Value"限制其可能的应用。
20. 允许接口中的运算符，并实现所有核心号码类型IArithmetic；其他有用的共享操作员界面也是可能的，
21. 使对象字段/属性发生变异变得更加困难，或者至少允许对不可变字段进行注释，并使类型检查器强制执行它（只需将其视为仅用于吸气剂的属性，这并不难！）；实际上，以一种更明智的方式统一字段和属性，因为没有必要同时拥有两者；C＃3.0的自动属性是朝着这个方向迈出的第一步，但还远远不够，
    • 更新：尽管C＃具有readonly关键字，并且C＃6.0添加了只读自动属性，但是它不像对不可变类型和值的真实语言支持那样严格。
22. 简化声明构造函数；我喜欢F＃的方法，但这里的另一篇文章至少要求“ new”而不是类名更好，

我想现在就足够了。这些都是我过去一周遇到的烦恼。如果我真的下定决心，我可能会继续工作几个小时。C＃4.0已经添加了命名，可选和默认参数，我对此表示赞同。

现在，对于一个不合理的请求：

1. 如果C＃/ CLR可以支持类型构造函数多态，那就真的非常好。泛型优于泛型，

漂亮吗？:-)

• 上的Reset()方法IEnumerator<T>是错误的（对于迭代器块，语言规范甚至要求这引发异常）
• 在埃里克看来，返回数组的反射方法是一个错误
• 数组协方差过去是，现在仍然是奇数
  • 更新：带有.NET 4.0的C＃4.0向通用接口（如IEnumerable<out T>和Func<in T, out TResult>，但没有具体类型（如List<T>））添加了协变/逆方差支持。
• ApplicationException 而是失宠了-这是一个错误吗？
• 同步集合-一个好主意，但实际上不一定有用：您通常需要同步多个操作（Contains，然后是Add），因此同步不同操作的集合并没有那么有用
  • 更新：该System.Collections.Concurrent类型的，有TryAdd，GetOrAdd，TryRemove，等在.NET Framework 4.0中增加-尽管接受工厂委托方法不能保证工厂将只调用每个键一次做。
• using/lock模式可能会得到更多使用-也许允许它们共享可重用（可扩展的）语法；您可以通过返回IDisposable并使用using，但可能更清楚了
• 迭代器块：没有一种简单的提前检查参数的方法（而不是懒惰地）。当然，您可以编写两个链接方法，但这很丑陋
• 简单的不变性会很好；C＃4.0帮助一点，但不是很够
• 不支持“此ref-type参数不能为null”-尽管合同（在4.0中）对此有所帮助。但是像Foo(SqlConnection! connection)（注入null-check / throw）这样的语法会很好（与int?etc对比）
  • 更新：这在C＃8.0中已修复。
• 缺少运算符和泛型的非默认构造函数的支持；C＃4.0使用可以解决此问题dynamic，也可以像这样启用它
• 迭代器变量在扩展中的while之外声明foreach，这意味着匿名方法/ lambda捕获单个变量，而不是每次迭代捕获一个变量（线程/异步/等痛苦）
  • 更新：这已在C＃5.0中修复。

TextWriter是StreamWriter的基类。wtf？

这总是使我感到困惑。

C＃小技巧-构造函数使用C ++ / Java语法，使构造函数与类同名。

New()否则ctor()会更好。

可以肯定的是，诸如Coderush之类的工具使得重命名类的问题减少了，但是从可读性的角度来看，New（）提供了极大的清晰度。

我不明白你做不到

其中T：new（U）

因此，您声明泛型T具有非默认构造函数。

编辑：

我想做这个：

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

我是第一个提到这个的人，我真的很惊讶：

ADO.NET类型的数据集不会将可空列公开为可空类型的属性。您应该可以这样写：

int? i = myRec.Field;
myRec.Field = null;

相反，您必须编写以下代码，这很愚蠢：

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

在.NET 2.0中，这很烦人，现在更烦人的是，您必须在漂亮的LINQ查询中像上面那样使用jiggery-pokery。

同样令人烦恼的是，生成的Add<TableName>Row方法对于可空类型的概念同样不明智。更重要的是，因为生成的TableAdapter方法不是。

.NET中没有太多内容使我感到开发团队说：“好吧，男孩们，我们已经足够亲密-运送它！” 但这确实可以。

1. 我不是Stream，StringWriter，StringReader，TextReader，TextWriter类的忠实拥护者...这不是很直观的概念。
2. IEnumerable.Reset引发迭代器异常。我有一些第三方组件，它们在数据绑定时总是调用reset，要求我首先转换为列表才能使用它们。
3. Xml Serializer应该具有序列化IDictionary元素
4. 我完全忘记了HttpWebRequest和FTP API，这给我带来了什么痛苦。

编辑
5.我的另一个烦恼是System.Reflection.BindingFlags如何根据您使用的方法具有不同的用途。例如在FindFields中，CreateInstance或SetField是什么意思？在这种情况下，他们已经使此枚举背后的含义过载了，这很令人困惑。

我不知道我会说这是一个设计缺陷，但是如果您可以像在VB中一样推导lambda表达式，那将非常好：

VB：

Dim a = Function(x) x * (x - 1)

C＃

如果可以这样做会很好：

var a = x => x * (x - 1);

不必这样做：

Func<int, int> a = x => x * (x - 1);

我意识到这已经不多了，但是在Code Golf中，每个角色都很重要！他们在设计这些编程语言时没有考虑到这一点吗？:)

1. 该System.Object的类：

   • Equals和GetHashCode-并非所有类都是可比较的或可哈希的，应将其移至接口。想到IEquatable或IComparable（或类似版本）。

   • ToString-并非所有类都可以转换为字符串，应将其移至接口。我想到了IFormattable（或类似格式）。

2. 该ICollection.SyncRoot属性：

   • 提升设计质量，外部锁几乎总是更有用。

3. 泛型应该从一开始就存在：

   • 该System.Collections中命名空间包含了很多或多或少过时的类和接口。

令我烦恼的是Predicate<T> != Func<T, bool>悖论。他们都是类型的委托，T -> bool但它们与分配不兼容。

某些人（ISV）希望您可以在构建时将其编译为机器代码并进行链接，以创建不需要dotNet运行时的本机可执行文件。

我们对正确的OO技术了解很多。解耦，按合同编程，避免不正确的继承，异常的适当使用，打开/关闭的主体，Liskov可替换性等等。到目前为止，.Net框架还没有采用最佳实践。

对我来说，.Net设计中最大的缺陷不是站在巨人的肩膀上；而是在互联网上。向使用框架的程序员推广不太理想的编程范例。

如果MS对此予以关注，那么在这十年中，软件工程界可能在质量，稳定性和可伸缩性方面取得了巨大飞跃，但是可惜，它似乎正在倒退。

我不喜欢C＃switch语句。

我想要这样的东西

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

因此，不再有中断（容易忘记）的可能性，并且可以用逗号分隔不同的值。

C＃中的事件，您必须在其中显式检查侦听器。广播事件的重点不是向碰巧在那里的任何人广播吗？即使没有？

嵌套/递归迭代器的可怕的（对大多数人来说是不可见的）O（N ^ 2）行为。

我很胆怯，他们知道这件事，知道如何解决它，但它不被认为具有应优先考虑的优点。

我一直在使用类似树的结构，当聪明的人无意中以这种方式引入昂贵的操作时，他们必须更正他们的代码。

“ yield foreach”的好处在于，更简单，更容易的语法鼓励正确，高效的代码，这就是“成功之道”。，我想他们增加新的功能，为平台的长期成功之前，应该向往。

一些类实现接口，但它们未实现该接口的许多方法，例如Array实现IList，但9种方法中有4种抛出NotSupportedException http://msdn.microsoft.com/zh-cn/library/system.array_members .aspx

接口中的静态成员和嵌套类型。

这是特别有用当一个接口件具有一类型的参数是特定于接口（例如一个enum）。将枚举类型嵌套在接口类型中会很好。

事件的极其危险的默认性质。由于删除了订阅者，您可以调用事件并处于不一致状态的事实真是太可怕了。有关该主题的更多阅读信息，请参见Jon Skeet和Eric Lippert的优秀文章。

• null 到处。

• const 无处。

• API是不一致的，例如，对数组return进行变异，void但在return后面追加StringBuffer相同的mutable StringBuffer。

• 集合接口与不可改变的数据结构不兼容，例如，Add在System.Collections.Generic.IList<_>无法返回结果。

• 没有结构性的类型，因此您可以编写System.Windows.Media.Effects.SamplingMode.Bilinear而不是Bilinear。

• IEnumerator由类实现的可变接口，当它应该是不可变的时struct。

• 平等和比较是一个烂摊子：你有System.IComparable和Equals，但是随后你也有System.IComparable<_>，System.IEquatable，System.Collections.IComparer，System.Collections.IStructuralComparable，System.Collections.IStructuralEquatable，System.Collections.Generic.IComparer和System.Collections.Generic.IEqualityComparer。

• 元组应该是结构，但是结构不必要地抑制了尾部调用消除，因此最常见和基本的数据类型之一将不必要地分配并破坏可伸缩并行性。

0月光作为枚举

枚举的特性： http //blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

如这个好例子所示： http //plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

我的建议，请充分利用“ @”符号：

代替：

如果（（myVar＆MyEnumName.ColorRed）！= 0）

用这个：

如果（（myVar＆MyEnumName.ColorRed）！= @ 0）

要添加一长串已经由他人提出的优点：

• DateTime.Now == DateTime.Now 在大多数情况下（并非所有情况下）。

• String这是不可变的，具有一堆构造和操作选项，但StringBuilder（可变）没有。

• Monitor.Enter并且Monitor.Exit应该是实例方法，因此您可以新建一个aMonitor并对其进行锁定，而不是为锁定而新建一个特定的对象。

• 绝对不应将析构函数命名为析构函数。ECMA规范称它们为终结器，对于C ++人群来说，混淆器要少得多，但是语言规范仍将它们称为析构函数。

我们使用属性的方式有时让我感到恼火。我喜欢将它们视为Java的getFoo（）和setFoo（）方法的等效项。但事实并非如此。

如果《属性使用指南》指出应该可以以任何顺序设置属性，以便可以进行序列化，那么它们对于设置时间验证是无用的。如果您来自一个想防止对象自身进入无效状态的背景，那么属性不是您的解决方案。有时我看不到他们比公众成员更好，因为我们在应该考虑的事情上受限制在房地产领域做。

为此，我一直都希望（可以在这里大声思考，只是希望可以做这样的事情）我可以某种方式扩展属性语法。想象这样的事情：

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

我不确定这是否有用，或者访问这些东西会是什么样子。但是我只是希望我可以对属性做更多的事情，并像对待get和set方法一样对待它们。

扩展方法虽然不错，但是对于解决本来可以用真正的mixins解决的问题而言，这是一种丑陋的方式（请参阅ruby以了解我在说什么）。将它们添加到语言中的一种非常不错的方法是允许将泛型用于继承。这允许您以一种很好的面向对象的方式扩展现有的类：

public class MyMixin<T> : T
{
    // etc...
}

可以像这样使用它来扩展字符串，例如：

var newMixin = new MyMixin<string>();

它比扩展方法功能强大得多，因为它允许您重写方法，例如将它们包装起来，从而在语言内部提供类似于AOP的功能。

对不起，咆哮:-)

Microsoft不会修复框架中的明显错误，也不会提供挂钩，以便最终用户可以修复它们。

另外，在运行时无法对.NET可执行文件进行二进制修补，也无法在不对本机库进行二进制修补（以拦截加载调用）的情况下指定.NET Framework库的私有版本，并且ILDASM无法重新分发，因此我无法实现自动化反正补丁。

• 能否在null变量上调用扩展方法是有争议的，例如

  对象a = null; a.MyExtMethod（）; //这是可以调用的，假设它已经定义了MyExtMethod

  它可能很方便，但是在空引用异常主题上模棱两可。

• 一种命名为“缺陷”。System.configuration.dll中“配置”的“ C”应大写。

• 异常处理。应该像Java中那样强制捕获或引发异常，编译器应在编译时对其进行检查。用户不应依赖注释来获取目标调用中的异常信息。

框架V1中SqlCommand上的.Parameters.Add（）方法是经过可怕设计的-如果您传递的值（int）为0，则重载之一基本上将不起作用-这导致它们创建SqlCommand类上的.Parameters.AddWithValue（）方法。

1. ICollection<T>和没有子集IList<T>；至少，协变只读集合接口IListSource<out T>（带有枚举器，索引器和Count）将非常有用。
2. .NET不支持弱委托。解决方法充其量是笨拙的，在部分信任中，侦听器端的解决方法是不可能的（需要ReflectionPermission）。
3. 即使合理且不会造成任何问题，也禁止通用接口统一。
4. 与C ++不同，.NET中不允许协变返回类型
5. 不可能对两种值类型进行按位比较以得出相等性。在功能性的“持久”数据结构中，我正在编写一个Transform(Sequence<T>, Func<T,T>)功能，功能需要快速确定该功能返回的是相同值还是不同值。如果函数未修改其大部分/所有参数，则输出序列可以共享输入序列中的部分/全部内存。如果无法按位比较任何值类型T，则必须使用慢得多的比较，这会严重损害性能。
6. .NET似乎无法以高性能的方式支持即席界面（如Go或Rust中提供的那些）。即使该类未显式实现该接口，此类接口也将允许您强制List<T>转换为假设IListSource<U>（T：U）。至少有三个 不同的 库（独立编写）来提供此功能（当然，在性能方面存在缺陷-如果可能有一个完美的解决方法，则称它为.NET缺陷是不公平的）。
7. 其他性能问题：IEnumerator每次迭代需要两个接口调用。普通方法指针（IntPtr大小的打开委托）或值类型的委托（IntPtr * 2）是不可能的。固定大小的数组（任意类型T）不能嵌入类中。没有WeakReference<T>（您可以轻松编写自己的脚本，但是它将在内部使用强制类型转换。）
8. 在某些情况下（例如Predicate<T>vs Func<T,bool>），相同的委托人类型被认为是不兼容的（没有隐式转换），这对我来说是个麻烦。我经常希望我们可以进行结构化打字对接口和委托，以实现组件之间的松散耦合，因为在.NET中，独立DLL中的类不足以实现相同的接口-它们还必须共享对第三个对象的公共引用定义接口的DLL。
9. DBNull.Value即使null本来可以很好地达到相同的目的，也存在。
10. C＃没有?? =运算符；你必须写variable = variable ?? value。实际上，C＃中有一些地方不必要地缺乏对称性。例如，您可以书写if (x) y(); else z();（不带花括号），但不能书写try y(); finally z();。
11. 创建线程时，不可能使子线程从父线程继承线程局部值。BCL不仅不支持此功能，而且除非您手动创建所有线程，否则您无法自己实现它。即使发生线程创建事件，.NET也无法告诉您“父母”或“孩子”给定线程。
12. 对于不同的数据类型，有两个不同的长度属性，即“长度”和“计数”，这是一个小麻烦。
13. 关于WPF的糟糕设计，我可以永远继续下去，而且WCF（尽管在某些情况下非常有用）也充斥着疣。通常，许多BCL较新的子库the肿，不直观且文档有限，这使我不愿使用它们。许多新东西本来可以更简单，更小，更易于使用和理解，更松散地耦合，文档更好，适用于更多用例，更快和/或更强类型。
14. 我经常被属性获取器和设置器之间不必要的耦合所困扰：在派生类或派生接口中，当基类或基本接口只有一个吸气剂时，您不能简单地添加设置器。如果您覆盖了一个getter，那么您将不能定义setter；并且您不能将setter定义为虚拟的，而将getter定义为非虚拟的。

使用时我很生气在1.x的一件事是System.Xml.XmlValidatingReader，在ValidationEventHandler的ValidationEventArgs不露出下面的XmlSchemaException（标记内部），其中有像所有有用的信息linenumber和position。相反，您应该从Message字符串属性中解析此内容，或使用反射将其挖掘出来。当您要向最终用户返回更有效的错误时，效果不是很好。

不喜欢不能在另一个枚举中使用一个枚举的值，例如：

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

隐式类型变量在IMO中的实现效果很差。我知道您实际上只应该在使用Linq表达式时使用它们，但是令人讨厌的是，您不能在本地范围之外声明它们。

从MSDN：

• var仅可在同一语句中声明和初始化局部变量时使用；该变量不能初始化为null，方法组或匿名函数。
• var不能在类范围内的字段上使用。
• 使用var声明的变量不能在初始化表达式中使用。换句话说，此表达式是合法的：int i =（i = 20）; 但是此表达式会产生编译时错误：var i =（i = 20）;
• 多个隐式类型的变量不能在同一条语句中初始化。
• 如果范围内名为var的类型，则var关键字将解析为该类型名称，并且不会被视为隐式类型的局部变量声明的一部分。

我认为这是一个较差的实现，是因为他们将其称为var，但距离变体还有很长的路要走。它实际上只是不需要输入完整类名的简写语法（与Linq一起使用时除外）