Các tính năng C # hoặc .Net để cắt đứt giả sử không cần tương thích ngược? [đóng cửa]

Bất kỳ sản phẩm hoặc khung phát triển. Chủ yếu là nó được thực hiện để bắt kịp nhu cầu của người dùng, tận dụng sức mạnh tính toán mới và chỉ đơn giản là làm cho nó tốt hơn. Đôi khi mục tiêu thiết kế chính cũng thay đổi với sản phẩm. Khung C # hoặc .net cũng không ngoại lệ. Như chúng ta thấy, phiên bản thứ 4 ngày nay khác rất nhiều so với phiên bản đầu tiên. Nhưng điều này đến như một chướng ngại vật cho sự tương thích ngược tiến hóa này.

Trong hầu hết các khung / sản phẩm, có các tính năng sẽ bị cắt nếu không cần hỗ trợ tương thích ngược. Theo bạn, những tính năng này trong C # /. Net là gì?

Hãy đề cập đến một tính năng cho mỗi câu trả lời.

Phương pháp ẩn danh . Tôi nghĩ rằng mọi người đều đồng ý rằng cú pháp phương thức ẩn danh được chọn cho C # 2.0 là chunky và cồng kềnh so với cú pháp lambda mà chúng tôi đã thêm vào C # 3.0. Thật đáng tiếc khi có hai cú pháp gần như giống hệt nhau để làm điều tương tự.

Tôi sẽ thoát khỏi các bộ sưu tập Không chung chung. Chúng là một thứ gớm ghiếc ... và có quá nhiều trường hợp tôi đang sử dụng linq và phải làm một cái gì đó như

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

Mỗi lần tôi phải làm điều đó, một phần nhỏ trong tâm hồn tôi chết đi.

void như một loại . Tại sao trên trái đất là "void" một loại? Nó không có phiên bản, nó không có giá trị, bạn không thể sử dụng nó làm đối số loại chung, loại tham số chính thức, loại cục bộ, loại trường hoặc loại thuộc tính. Nó không có ý nghĩa như một loại; đúng hơn, đó là một thực tế về tác động của một cuộc gọi phương thức đối với ngăn xếp của máy ảo. Nhưng máy ảo chỉ có thế: một máy ảo. Máy thật sẽ đặt giá trị trả về vào một thanh ghi (thường là EAX trên x86) và hoàn toàn không ảnh hưởng đến ngăn xếp! Vô hiệu như một loại chỉ là một ý tưởng tồi xung quanh.

Tệ hơn: khi được sử dụng trong một loại con trỏ như trong void*nó có nghĩa là một cái gì đó hoàn toàn khác với những gì nó có nghĩa là khi được sử dụng như một loại trả về. Bây giờ nó có nghĩa là "một con trỏ đến một vị trí lưu trữ không xác định", không liên quan gì đến ý nghĩa của nó là "một phương thức không trả về bất kỳ giá trị nào".

Chúng ta có thể thay thế void*như một loại con trỏ với IntPtr. (Và void**với IntPtr*và vân vân.) Chúng tôi có thể thay thế khoảng trống như một kiểu trả về với "Đơn vị", một loại mà có một giá trị duy nhất, cụ thể là, null. Việc triển khai CLR sau đó có thể quyết định rằng một lệnh gọi hàm đơn vị có thể tối ưu hóa việc sử dụng các thanh ghi hoặc ngăn xếp của nó một cách thích hợp, biết rằng null được "trả về" có thể được bỏ qua một cách an toàn.

Trong một thế giới như vậy, bạn không còn cần tách biệt Func<A, R>và Action<T>đại biểu. Action<T>chỉ là Func<T, Unit>.

Những tuyên bố trống rỗng; . Dễ bị lỗi, hầu như luôn luôn là một lỗi đánh máy và không cung cấp cho bạn ý nghĩa bổ sung nào chưa được thể hiện bằng {}.

Hiệp phương sai không an toàn trên mảng kiểu tham chiếu . Với hiệp phương sai kiểu trên IEnumerable<T>, ít nhất một số nhu cầu về hiệp phương sai mảng đã biến mất. (Nếu chúng ta có giao diện danh sách chỉ đọc covariant thì chúng ta sẽ không cần đến nó.)

Toán tử đơn nguyên cộng . Toán tử hữu ích nhất mọi thời đại. Nếu chúng ta không phải giữ nó cho compat ngược, tôi sẽ lấy nó ra trong tích tắc. Ai sử dụng thứ này, có ai không?

(Làm rõ: Toán tử cộng đơn +xkhông phải là toán tử preincrement ++x, không phải toán tử postincrement x++và không phải là toán tử cộng nhị phân x+y.)

Mặc định chữ số thành double

Đối với hầu hết các ứng dụng kinh doanh , decimaldù sao thì cũng phù hợp hơn ... hoặc có lẽ sẽ tốt hơn nếu chỉ xóa ý tưởng về mặc định và buộc nhà phát triển thực sự đưa ra lựa chọn.

(Việc "xóa mặc định" cũng phù hợp với một số thứ khác. Ví dụ, tôi đã từ bỏ việc cố gắng thuyết phục mọi người rằng các lớp nên được niêm phong theo mặc định, nhưng tôi nghi ngờ việc thuyết phục mọi người rằng họ nên nghĩ về nó dễ dàng hơn liệu lớp mới của họ có nên được niêm phong hay không và làm cho nó rõ ràng.)

Đây là một hướng dẫn hơn là một tính năng, nhưng tôi nghĩ nó quan trọng bởi vì nó đã ăn sâu vào tâm trí của mọi người như là giải pháp kinh điển và tốt nhất:

Các mô hình chính thức để thực hiện IDisposable.

Đó là cồng kềnh và có những cách tốt hơn .

Tôi biết có sự khác biệt lớn giữa các lớp hẹn giờ khác nhau. Nhưng dù sao chúng ta cũng không thể thoát khỏi một hoặc hai trong số họ?

Các phương thức và loại Arrayvà List<T>đã trở nên lỗi thời với Linq, ví dụ:

• Array.TrueForAll có thể được thay thế bằng Enumerable.All
• Array.FindAll có thể được thay thế bằng Enumerable.Where
• List<T>.ConvertAll có thể được thay thế bằng Enumerable.Select
• Predicate<T> có thể được thay thế bằng Func<T, bool>
• Converter<T,R> có thể được thay thế bằng Func<T, R>
• IComparer<T> thực sự nên là một đại biểu Func<T, T, int>

Các đại biểu không chung chung Giống như các bộ sưu tập không chung chung, các đại biểu không chung chung bây giờ vô dụng khi chúng ta có chuỗi Func và Action. Và tôi đã cắt bỏ các biến thể ở ba tham số. Nếu bạn có nhiều hơn ba tham số, tạo cấu trúc và sử dụng tham số đó làm tham số đơn. Tuyên bố một đại biểu cụ thể để xử lý sự kiện không phải là rất DRY.

Dịch vụ web asmx

Tôi nghĩ rằng họ khá lỗi thời với WCF ngày nay.

Winforms
Thật tốt khi không phải điều hướng giữa hai nền tảng máy tính để bàn. WPF là nơi mọi thứ đang diễn ra, vì vậy thật bực bội khi có sự dư thừa ở cấp độ nền tảng.