이전 버전과의 호환성이 필요하지 않다고 가정하는 C # 또는 .Net 기능? [닫은]

모든 제품 또는 프레임 워크가 진화합니다. 주로 사용자의 요구를 충족시키고 새로운 컴퓨팅 기능을 활용하며 단순히 개선하기 위해 수행됩니다. 때로는 기본 디자인 목표가 제품에 따라 변경 될 수도 있습니다. C # 또는 .net 프레임 워크도 예외는 아닙니다. 보시다시피, 현재의 네 번째 버전은 첫 번째 버전과 비교하여 매우 다릅니다. 그러나이 진화-후진 호환성에 장애물이됩니다.

대부분의 프레임 워크 / 제품에는 이전 버전과의 호환성을 지원할 필요가없는 경우 기능이 차단되었을 수 있습니다. C # /. net에서 이러한 기능은 무엇입니까?

답변 당 하나의 기능을 언급하십시오.

익명의 방법 . C # 2.0에서 선택한 익명 메서드 구문이 C # 3.0에 추가 한 람다 구문과 비교할 때 엉성하고 어색하다는 데 모두가 동의한다고 생각합니다. 거의 같은 두 가지 구문을 사용하여 동일한 작업을 수행하는 것은 매우 유감입니다.

비 제네릭 컬렉션을 제거합니다. 그들은 혐오입니다 ... 그리고 linq를 사용하고 있고 뭔가를 해야하는 경우가 너무 많습니다.

var customObjects = container.CustomObjects.Cast<CustomObject>();

그렇게해야 할 때마다 내 영혼의 작은 부분이 죽습니다.

유형으로 void . 왜 지구상에서 유형이 "무효"입니까? 인스턴스가없고 값이 없으며 일반 유형 인수, 형식 매개 변수 유형, 로컬 유형, 필드 유형 또는 특성 유형으로 사용할 수 없습니다. 유형으로서의 의미는 없습니다. 오히려 메서드 호출이 가상 시스템의 스택 에 어떤 영향을 미치는지 에 대한 사실 입니다. 그러나 가상 머신은 바로 가상 머신입니다. 실제 머신은 반환 된 값을 레지스터 (일반적으로 x86의 EAX)에 넣고 스택에 전혀 영향을 미치지 않습니다! 유형으로서의 무효는 단지 나쁜 생각입니다.

더 나쁜 : 같이 포인터 타입에 사용하면 void*뭔가 의미 완전히 다른 반환 유형으로 사용될 때 그것은 무엇을 의미하는지에 비해합니다. 이제 "알 수없는 유형의 저장 위치에 대한 포인터"를 의미하며, "값을 반환하지 않는 메소드"라는 의미와는 아무런 관련이 없습니다.

void*포인터 타입으로 대체 할 수 있습니다 IntPtr. (그리고 void**함께 IntPtr*등등.) 우리는 "단위", 단일 값, 즉, 널 (null)이있는 유형의 반환 형식으로 무효 교체 할 수 있습니다. CLR의 구현은 "반환되는"널이 안전하게 무시 될 수 있다는 것을 알면서 단위 유형 함수 호출이 레지스터 또는 스택의 사용을 적절하게 최적화 할 수 있다고 결정할 수 있습니다.

이러한 세계에서는 더 이상 분리 할 필요가 없다 Func<A, R>와 Action<T>위임한다. Action<T>그냥 Func<T, Unit>입니다.

빈 문장; . 오류가 발생하기 쉽고 거의 항상 오타이며 아직로 표현되지 않은 추가 의미는 제공하지 않습니다 {}.

참조 유형의 배열에서 안전하지 않은 공분산 . typesafe 공분산이 설정 IEnumerable<T>되면 배열 공분산에 대한 필요성이 사라졌습니다. (공변량 읽기 전용 목록 인터페이스가 있으면 전혀 필요하지 않습니다.)

단항 플러스 연산자 . 역대 가장 유용한 연산자. 만약 우리가 이전 버전과의 호환성을 위해 그것을 유지할 필요가 없다면, 나는 그것을 심장 박동으로 꺼낼 것이다. 누가 이걸 사용합니까?

(설명 : 단항 더하기 연산자 +x는 사전 ++x증가 연산자가 아니며, 증가 후 연산자 x++가 아니며 2 진 덧셈 연산자가 아닙니다 x+y.)

숫자 리터럴을 기본값으로 double

대부분의 비즈니스 응용 프로그램의 decimal경우 어쨌든 더 적합합니다 ... 또는 기본 아이디어를 제거 하고 개발자가 실제로 선택하도록 강요하는 것이 좋습니다.

예를 들어, 나는 모든 사람들이 기본적으로 봉인되어야한다는 설득을 포기했지만 사람들이 생각 해야 한다고 설득하기가 더 쉽다고 생각 한다. 새 수업을 봉인해야하는지 여부를 명시 적으로 명시해야합니다.)

이것은 기능보다 지침이지만, 이미 사람들의 마음에 정식적이고 최상의 솔루션으로 너무 많이 뿌리 박혀 있기 때문에 중요하다고 생각합니다.

공식 패턴 구현 IDisposable.

번거롭고 더 좋은 방법이 있습니다.

내가 알고있는 다양한 타이머 클래스 사이에 큰 차이가 있습니다. 그러나 어쨌든 우리는 그것들 중 하나 나 둘을 제거 할 수 없었습니까?

Linq에서 사용되지 않는 방법 및 유형은 다음 Array과 List<T>같습니다.

• Array.TrueForAll 로 교체 가능 Enumerable.All
• Array.FindAll 로 교체 가능 Enumerable.Where
• List<T>.ConvertAll 로 교체 가능 Enumerable.Select
• Predicate<T> 로 교체 가능 Func<T, bool>
• Converter<T,R> 로 교체 가능 Func<T, R>
• IComparer<T> 정말 대리 자야 Func<T, T, int>

제네릭이 아닌 대표자 제네릭이 아닌 컬렉션들과 마찬가지로, 우리가 Func and Action 시리즈를 가지고 있기 때문에 제네릭이 아닌 대리인은 쓸모가 없습니다. 그리고 세 가지 매개 변수에서 변형을 차단했을 것입니다. 세 개 이상의 매개 변수가있는 경우 구조를 만들어 단일 매개 변수로 사용하십시오. 이벤트 처리를 위해 특정 델리게이트를 선언하는 것은 그리 건조하지 않습니다.

asmx 웹 서비스

요즘 WCF에서는 더 이상 쓸모가 없다고 생각합니다.

Winforms
두 데스크탑 플랫폼 사이를 이동할 필요가없는 것이 좋습니다. WPF는 상황이 진행되는 곳이므로 플랫폼 수준의 이중화가 완전히 필요합니다.