C # (. NET) 디자인 결함 [닫힌]

일반적으로 C # 또는 .NET Framework의 가장 큰 디자인 결함은 무엇입니까?

예 : nullable이 아닌 문자열 유형이 없으며 IDataReader에서 값을 가져올 때 DBNull을 확인해야합니다.

나는 이 게시물에 단호하게 동의합니다 (ToString이 부족한 사람들을 위해 클래스에 대한 사용자 정의 형식을 제공하는 디버거 속성이 있습니다).

위의 목록 위에 다음과 같은 합리적인 요청을 추가합니다.

1. nullable 값 형식에 대한 보완으로서 nullable이 아닌 참조 형식,
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. 2 차 열거 가능 동작 수정 ,
11. 모든 컬렉션에는 반복을 위해 변경할 수없는 스냅 샷이 있어야합니다 (예 : 컬렉션을 변경하면 반복자가 무효화되지 않아야 함).
12. 튜플은 추가하기 쉽지만 " Either<T>" 와 같은 효율적인 폐쇄 형 대수 유형 은 그렇지 않습니다. 따라서 폐쇄 형 대수 유형을 선언하고 철저한 패턴 일치를 적용하는 방법을 좋아합니다 (기본적으로 방문자 패턴에 대한 일급 지원이지만 훨씬 더 효율적입니다. 따라서 열거 형을 취하고 철저한 패턴 일치 지원으로 확장하고 유효하지 않은 경우를 허용하지 마십시오.
13. 일반적으로 패턴 매칭에 대한 지원을 원하지만 최소한 객체 유형 테스트에 대해서는 지원합니다. 나는 또한 여기 다른 게시물에서 제안한 스위치 구문과 비슷합니다.
14. System.IO같은 클래스 Stream가 다소 잘못 설계 되었다는 다른 게시물에 동의합니다 . 일부 구현이 필요한 인터페이스 NotSupportedException는 잘못된 디자인입니다.
15. IList현재보다 훨씬 간단해야합니다. 사실, 이것은 다음과 같은 많은 구체적인 컬렉션 인터페이스에 해당 될 수 있습니다 ICollection.
16. 예를 들어 IDictionary와 같은 예외가 너무 많은 메서드에서 발생합니다.
17. Java에서 사용할 수있는 것보다 더 나은 확인 된 예외 형식을 선호합니다 (이 작업을 수행하는 방법에 대해서는 유형 및 효과 시스템에 대한 연구 참조).
18. 일반적인 메서드 오버로드 해결에서 다양한 성가신 코너 케이스를 수정합니다. 예를 들어, 참조 유형에서 작동하는 두 개의 오버로드 된 확장 메소드를 제공하고 다른 하나는 nullable 구조체 유형에서 작동하고 유형 추론이 어떻게 좋아하는지 확인하십시오.
19. INotifyPropertyChanged필드 이름을 문자열로 사용하는 인터페이스의 필드 및 멤버 이름을 안전하게 반영하는 방법을 제공 합니다. MemberExpression, 즉 람다를 사용하는 확장 메서드를 사용하여이를 수행 할 수 있습니다 . () => Foo하지만 그다지 효율적이지 않습니다.
    • 업데이트 : C # 6.0 nameof()은 단일 멤버 이름에 대한 연산자를 추가 했지만 제네릭에서는 작동하지 않습니다 ( nameof(T) == "T"실제 형식 인수 이름 대신 수행해야 함 typeof(T).Name))- "경로"문자열을 가져올 수도 없습니다. , 예 : nameof(this.ComplexProperty.Value) == "Value"가능한 응용 프로그램 제한.
20. 인터페이스에서 연산자를 허용하고 모든 핵심 번호 유형이 구현되도록합니다 IArithmetic. 다른 유용한 공유 운영자 인터페이스도 가능합니다.
21. 객체 필드 / 속성을 변경하는 것을 더 어렵게 만들거나, 최소한 불변 필드에 주석을 달 수 있도록 허용하고 유형 검사기가이를 강제하도록합니다 (단지 chrissakes에서 getter 전용 속성으로 취급하면 어렵지 않습니다!). 사실 필드와 속성을 더 합리적으로 통합해야합니다. 둘 다 가지는 데는 의미가 없기 때문입니다. C # 3.0의 자동 속성은이 방향의 첫 번째 단계이지만 충분하지 않습니다.
    • 업데이트 : C #에는 readonly키워드가 있고 C # 6.0은 읽기 전용 자동 속성을 추가했지만 변경 불가능한 유형 및 값에 대한 실제 언어 지원만큼 엄격하지는 않습니다.
22. 선언 생성자를 단순화합니다. 나는 F #의 접근 방식을 좋아하지만, 클래스 이름 대신 단순히 "new"가 필요한 다른 게시물은 적어도 더 좋습니다.

지금은 충분하다고 생각합니다. 이것들은 지난주에 내가 만난 모든 자극입니다. 정말로 마음을 쏟으면 몇 시간 동안 계속할 수있을 것입니다. C # 4.0은 이미 명명 된, 선택적 및 기본 인수를 추가하고 있습니다.

이제 한 가지 비합리적인 요청 :

1. C # / CLR이 형식 생성자 다형성을 지원할 수 있다면 정말 좋을 것 입니다. 제네릭보다 제네릭,

제발요? :-)

• 의 Reset()메서드 IEnumerator<T>가 실수였습니다 (반복자 블록의 경우 언어 사양 에서 예외가 발생하도록 요구 합니다)
• 배열을 반환하는 리플렉션 메서드는 Eric의 관점에서 실수 였습니다.
• 배열 공분산은 이상했고 여전히
  • 업데이트 : .NET 4.0이 포함 된 C # 4.0은 일반 인터페이스에 공변 / 반 변성 지원을 추가했습니다 ( IEnumerable<out T>및 Func<in T, out TResult>과 같지만 구체적인 형식 (예 :) 은 List<T>아님).
• ApplicationException 오히려 호의적으로 떨어졌습니다-그게 실수였습니까?
• 동기화 된 컬렉션-좋은 생각이지만 실제로는 유용하지는 않습니다. 일반적으로 여러 작업 ( Contains, then Add) 을 동기화해야 하므로 개별 작업을 동기화하는 컬렉션은 그다지 유용하지 않습니다.
  • 업데이트 : 유형 과는 , , , 등은 .NET 프레임 워크 4.0에 추가 된 - 공장의 위임을 받아 들일 방법이 공장은 키 당 한 번만 호출됩니다 보장하지 않습니다하지만.System.Collections.ConcurrentTryAddGetOrAddTryRemove
• using/ lock패턴을 더 많이 사용할 수 있습니다 .-아마도 재사용 가능한 (확장 가능한?) 구문을 공유 할 수 있습니다. 을 (를) 반환 IDisposable하고 사용하여 시뮬레이션 할 수 using있지만 더 명확 할 수 있습니다.
• 반복자 블록 : 인수를 미리 확인하는 간단한 방법이 없습니다 (지연하지 않고). 물론 두 개의 연결 메서드를 작성할 수 있지만 그것은 추합니다.
• 더 간단한 불변성은 좋을 것입니다. C # 4.0은 약간 도움 이 되지만 충분하지는 않습니다.
• "이 ref-type 매개 변수는 null 일 수 없습니다."지원은 없습니다. 그러나 계약 (4.0에서)이이 작업에 어느 정도 도움이됩니다. 그러나 Foo(SqlConnection! connection)(null-check / 주입) 와 같은 구문은 throw좋을 것입니다 (대비 int?등)
  • 업데이트 : 이 문제는 C # 8.0에서 수정되었습니다 .
• 제네릭을 사용하는 연산자 및 기본이 아닌 생성자의 지원 부족 C # 4.0 dynamic은을 사용 하여이 문제를 약간 해결 하거나 다음 과 같이 활성화 할 수 있습니다.
• 확장 에서 while 외부 에서 선언되는 반복기 변수 foreach, 즉 anon-methods / lambda가 반복 당 하나가 아닌 단일 변수를 캡처 함을 의미합니다 (스레딩 / 비동기 등으로 고통 스러움).
  • 업데이트 : 이것은 C # 5.0에서 수정되었습니다 .

TextWriter는 StreamWriter 의 기본 클래스입니다. 뭐?

그것은 항상 나를 극도로 혼란스럽게 만듭니다.

작은 C # pet peev-생성자는 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 형식화 된 데이터 집합은 nullable 형식의 속성으로 nullable 열을 노출하지 않습니다. 다음과 같이 작성할 수 있어야합니다.

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메서드가 nullable 형식의 개념과 비슷하게 무의미 하다는 것도 성가신 일입니다 . 생성 된 TableAdapter메서드가 아니기 때문에 더욱 그렇습니다 .

.NET에는 개발팀이 "좋아요, 우리는 충분히 가까웠습니다. 배송 해주세요!"라고 말한 것 같은 느낌이 들지 않습니다. 그러나 이것은 확실합니다.

1. 나는 Stream, StringWriter, StringReader, TextReader, TextWriter 클래스의 열렬한 팬이 아닙니다 ... 무엇이 무엇인지 직관적이지 않습니다.
2. IEnumerable.Reset이 반복기에 대한 예외를 발생시킵니다. 데이터 바인딩시 항상 재설정을 호출하는 타사 구성 요소가 있으며이를 사용하려면 먼저 목록으로 캐스팅해야합니다.
3. XML Serializer에는 직렬화 된 IDictionary 요소가 있어야합니다.
4. 나는 HttpWebRequest & FTP API에 대해 완전히 잊었다. 내 고통이 .... (Nicholas가 이것을 상기시켜 주셔서 감사합니다 :-)

편집
5. 또 다른 성가심은 System.Reflection.BindingFlags가 사용하는 방법에 따라 다른 용도로 사용된다는 것입니다. 예를 들어 FindFields에서 CreateInstance 또는 SetField는 무엇을 의미합니까? 이것은 그들이 혼란스러운이 열거 뒤에있는 의미를 오버로드 한 경우입니다.

디자인상의 결함이라고 말할 수 있을지는 모르겠지만, VB에서와 같은 방식으로 람다 식을 추론 할 수 있다면 정말 좋을 것입니다.

VB :

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

씨#

이렇게 할 수 있다면 좋을 것입니다.

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. Generics는 처음부터 있어야합니다.

   • 은 System.Collections의 네임 스페이스는 더 많거나 적은 오래된 클래스와 인터페이스를 많이 포함되어 있습니다.

저를 짜증나게하는 것 중 하나는 Predicate<T> != Func<T, bool>역설입니다. 둘 다 유형의 대리자 T -> bool이지만 할당과 호환되지 않습니다.

어떤 사람들 (ISV)은 dotNet 런타임이 필요하지 않은 네이티브 실행 파일을 만들기 위해 빌드 타임에 머신 코드로 컴파일하고 링크 할 수 있기를 바랍니다.

우리는 권리 에 대해 너무 많이 알고 있습니다. OO 기술 있습니다. 디커플링, 계약에 의한 프로그래밍, 부적절한 상속 방지, 적절한 예외 사용, 개방 / 폐쇄 주체, Liskov 대체 가능성 등. 아직 .Net 프레임 워크는 모범 사례를 사용하지 않습니다.

나에게 .Net 디자인의 가장 큰 결함은 거인의 어깨에 서 있지 않습니다. 프레임 워크를 사용하는 수많은 프로그래머에게 이상적이지 않은 프로그래밍 패러다임을 홍보 합니다.

MS가 이에주의를 기울 였다면 소프트웨어 엔지니어링 세계는 이번 10 년 동안 품질, 안정성 및 확장 성 측면에서 큰 도약을 할 수 있었지만 아쉽게도 퇴보하고있는 것 같습니다.

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을 throw합니다 . .aspx

인터페이스의 정적 멤버 및 중첩 유형.

인터페이스 부재는 인터페이스에 특정한 타입의 파라미터 (가질 때 특히 유용 예 을 enum). 인터페이스 유형에 열거 유형을 중첩하는 것이 좋습니다.

이벤트의 매우 위험한 기본 특성. 이벤트를 호출 할 수 있고 구독자가 제거되어 일관성이없는 상태에 있다는 사실은 끔찍합니다. 주제에 대한 자세한 내용은 Jon Skeet 및 Eric Lippert의 우수한 기사를 참조하십시오.

• null 어디에나.

• const 아무데도.

• API는 일관성이 없습니다. 예를 들어 배열을 변경하면 반환 void되지만에 추가 StringBuffer하면 동일한 mutable 이 반환 StringBuffer됩니다.

• 컬렉션 인터페이스는 불변 데이터 구조와 호환되지 않습니다. 예를 들어 Addin 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 달빛

enum의 특성 : 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

내 제안, "@"기호를 잘 사용하십시오.

대신에:

if ((myVar & MyEnumName.ColorRed)! = 0)

이것을 사용하십시오 :

if ((myVar & MyEnumName.ColorRed)! = @ 0)

이미 다른 사람들이 만든 좋은 점의 긴 목록에 추가하려면 :

• DateTime.Now == DateTime.Now 대부분의 경우이지만 모든 경우는 아닙니다.

• String불변 인 것은 구성과 조작을위한 많은 옵션을 가지고 있지만 StringBuilder(변할 수있는) 그렇지 않습니다.

• Monitor.Enter 과 Monitor.Exit 해야하고 인스턴스 메서드, 그래서 대신 잠금에 대해 특정 오브젝트를 newing, 그럴 수있어 새로 만들기 Monitor가에 및 잠금.

• 소멸자는 소멸자로 명명되어서는 안됩니다. ECMA 사양에서는이를 종료 자라고 부르며 C ++ 군중에게는 훨씬 덜 혼란 스럽지만 언어 사양에서는 여전히이를 소멸 자라고합니다.

우리가 속성을 사용하는 방식은 때때로 나를 짜증나게합니다. 나는 그것들을 Java의 getFoo () 및 setFoo () 메소드와 동등하다고 생각하고 싶습니다. 하지만 그렇지 않습니다.

는 IF 속성 사용 지침의 직렬화가 작동 할 수 있도록 속성 수 있어야 상태, 임의의 순서로 설정해야합니다 그들은있는 거 세터시의 검증을위한 쓸모. 개체가 잘못된 상태가되는 것을 방지하려는 배경에서 온 경우 속성은 솔루션이 아닙니다. 때때로 나는 그들이 공공 회원들보다 얼마나 더 나은지 보지 못합니다. 우리는 부동산에서 해야 할 일의 종류가 너무 제한 되어 있기 때문입니다.

이를 위해 저는 항상 속성 구문을 어떻게 든 확장 할 수 있기를 바랐습니다 (대부분 여기에서 큰 소리로 생각하고 있습니다. 저는 이런 식으로 할 수 있기를 바랍니다). 다음과 같이 상상해보십시오.

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 메서드처럼 처리 할 수 ​​있기를 바랍니다.

확장 방법은 좋지만 믹스 인의 주제에 대해 실제 믹스 인으로 더 깨끗하게 해결할 수있는 문제를 해결하는 추악한 방법입니다 (내가 말하는 내용을 보려면 루비를보세요). 그것들을 언어에 추가하는 정말 좋은 방법은 제네릭을 상속에 사용할 수있게하는 것이었을 것입니다. 이를 통해 기존 클래스를 멋진 객체 지향 방식으로 확장 할 수 있습니다.

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

다음과 같이 문자열을 확장하는 데 사용할 수 있습니다.

var newMixin = new MyMixin<string>();

예를 들어 언어 내부에서 AOP와 유사한 기능을 허용하는 래핑과 같이 메서드를 재정의 할 수 있기 때문에 확장 메서드보다 훨씬 강력합니다.

폭언 죄송합니다 :-)

Microsoft는 프레임 워크의 명백한 버그를 수정하지 않으며 최종 사용자가 수정할 수 있도록 후크를 제공하지 않습니다.

또한 런타임에 .NET 실행 파일을 바이너리 패치 할 수있는 방법이 없으며 네이티브 라이브러리를 바이너리 패치하지 않고 (로드 호출을 가로 채기 위해) .NET 프레임 워크 라이브러리의 비공개 버전을 지정할 방법이 없으며 ILDASM은 재배포 할 수 없으므로 자동화 할 수 없습니다. 어쨌든 패치.

• null 변수에 대한 확장 메서드를 호출 할 수 있어야합니다.

  개체 a = null; a.MyExtMethod (); // 이것은 호출 가능합니다. MyExtMethod를 정의한 어딘가에 가정합니다.

  편리 할 수는 있지만 null 참조 예외 항목에서는 모호합니다.

• 하나의 명명 '결함'. System.configuration.dll에서 "configuration"의 'C'는 대문자 여야합니다.

• 예외 처리. 예외는 Java에서와 같이 강제로 포착되거나 throw되어야하며 컴파일러는 컴파일시이를 확인해야합니다. 사용자는 대상 호출 내의 예외 정보에 대한 주석에 의존해서는 안됩니다.

프레임 워크 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.Valuenull동일한 목적을 똑같이 잘 수행했을 지라도 존재 합니다.
10. C #에는 ?? = 연산자가 없습니다. 작성해야합니다 variable = variable ?? value. 실제로 C #에는 불필요하게 대칭이 부족한 곳이 몇 군데 있습니다. 예를 들어 if (x) y(); else z();(중괄호없이) 쓸 수는 있지만 try y(); finally z();.
11. 스레드를 만들 때 자식 스레드가 부모 스레드에서 스레드 로컬 값을 상속하도록하는 것은 불가능합니다. BCL은이를 지원하지 않을뿐만 아니라 모든 스레드를 수동으로 생성하지 않는 한 직접 구현할 수 없습니다. 스레드 생성 이벤트가 있더라도 .NET 은 주어진 스레드 의 "부모"또는 "자식" 을 알려줄 수 없습니다 .
12. 서로 다른 데이터 유형에 대해 "Length"및 "Count"라는 두 가지 길이 속성이 있다는 사실은 사소한 문제입니다.
13. 나는 WPF의 열악한 디자인에 대해 영원히 계속할 수 있으며 WCF (일부 시나리오에서는 매우 유용하지만)도 사마귀로 가득 차 있습니다. 일반적으로 많은 BCL의 최신 하위 라이브러리에 대한 부풀음, 직관적이지 않음 및 제한된 문서화로 인해 사용하기가 꺼려집니다. 많은 새로운 것들이 훨씬 더 간단하고, 작고, 사용하기 쉽고, 더 느슨하게 결합되고, 더 잘 문서화되고, 더 많은 사용 사례에 적용되고, 더 빠르고, 더 강력하게 입력되었을 수 있습니다.
14. 나는 종종 속성 getter와 setter 사이의 불필요한 결합에 물렸다. 파생 클래스 또는 파생 인터페이스에서 기본 클래스 또는 기본 인터페이스에 getter 만 있으면 단순히 setter를 추가 할 수 없습니다. getter를 재정의하면 setter를 정의 할 수 없습니다. setter를 가상으로 정의 할 수 없지만 getter는 가상이 아닌 것으로 정의 할 수 있습니다.

를 사용하는 경우 1.x에서 저를 쳤다 것은 있었다 System.Xml.XmlValidatingReader의 ValidationEventHandler의가 ValidationEventArgs가 기본 노출하지 않습니다 XmlSchemaException같은 모든 유용한 정보를 가지고있는 (내부 표시) linenumber및 position. 대신 메시지 문자열 속성에서이를 구문 분석하거나 리플렉션을 사용하여 파싱해야합니다. 최종 사용자에게 좀 더 삭제 된 오류를 반환하려는 경우에는 좋지 않습니다.

한 열거 형의 값을 다른 열거 형에서 사용할 수 없다는 점이 마음에 들지 않습니다. 예를 들면 다음과 같습니다.

    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와 함께 사용하는 경우 제외).