Một cách sử dụng đúng của downcasting là gì?

Downcasting có nghĩa là truyền từ một lớp cơ sở (hoặc giao diện) sang một lớp con hoặc lớp lá.

Một ví dụ về downcast có thể là nếu bạn truyền từ System.Objectmột số loại khác.

Downcasting không phổ biến, có thể là mùi mã: Học thuyết hướng đối tượng là thích, ví dụ, xác định và gọi các phương thức ảo hoặc trừu tượng thay vì downcasting.

• Điều gì, nếu có, là trường hợp sử dụng tốt và thích hợp cho downcasting? Đó là, trong trường hợp nào là thích hợp để viết mã mà phát sóng?
• Nếu câu trả lời của bạn là "không", thì tại sao ngôn ngữ này lại được hỗ trợ bởi ngôn ngữ?

Dưới đây là một số cách sử dụng thích hợp của downcasting.

Và tôi tôn trọng kịch liệt không đồng ý với những người khác ở đây nói rằng việc sử dụng các chương trình truyền phát chắc chắn là một mùi mã, bởi vì tôi tin rằng không có cách hợp lý nào khác để giải quyết các vấn đề tương ứng.

Equals:

class A
{
    // Nothing here, but if you're a C++ programmer who dislikes object.Equals(object),
    // pretend it's not there and we have abstract bool A.Equals(A) instead.
}
class B : A
{
    private int x;
    public override bool Equals(object other)
    {
        var casted = other as B;  // cautious downcast (dynamic_cast in C++)
        return casted != null && this.x == casted.x;
    }
}

Clone:

class A : ICloneable
{
    // Again, if you dislike ICloneable, that's not the point.
    // Just ignore that and pretend this method returns type A instead of object.
    public virtual object Clone()
    {
        return this.MemberwiseClone();  // some sane default behavior, whatever
    }
}
class B : A
{
    private int[] x;
    public override object Clone()
    {
        var copy = (B)base.Clone();  // known downcast (static_cast in C++)
        copy.x = (int[])this.x.Clone();  // oh hey, another downcast!!
        return copy;
    }
}

Stream.EndRead/Write:

class MyStream : Stream
{
    private class AsyncResult : IAsyncResult
    {
        // ...
    }
    public override int EndRead(IAsyncResult other)
    {
        return Blah((AsyncResult)other);  // another downcast (likely ~static_cast)
    }
}

Nếu bạn định nói đây là những mùi mã, bạn cần cung cấp các giải pháp tốt hơn cho chúng (ngay cả khi chúng bị tránh do sự bất tiện). Tôi không tin giải pháp tốt hơn tồn tại.

Downcasting là không phổ biến, có thể là một mùi mã

Tôi không đồng ý. Downcasting là cực kỳ phổ biến ; một số lượng lớn các chương trình trong thế giới thực chứa một hoặc nhiều chương trình phát sóng. Và nó có thể không phải là một mùi mã. Nó chắc chắn là một mùi mã. Đó là lý do tại sao hoạt động downcasting được yêu cầu phải được hiển thị trong văn bản của chương trình . Nó để bạn có thể dễ dàng nhận thấy mùi hơn và dành sự chú ý đánh giá mã về nó.

Trong trường hợp nào thì thích hợp để viết mã mà phát sóng?

Trong mọi trường hợp:

• bạn có kiến thức đúng 100% về một thực tế về loại thời gian chạy của một biểu thức cụ thể hơn loại thời gian biên dịch của biểu thức và
• bạn cần tận dụng thực tế đó để sử dụng khả năng của đối tượng không khả dụng trên loại thời gian biên dịch và
• sử dụng thời gian và công sức để viết dàn diễn viên tốt hơn là tái cấu trúc chương trình để loại bỏ một trong hai điểm đầu tiên.

Nếu bạn có thể cấu trúc lại một chương trình một cách rẻ tiền để loại thời gian chạy có thể được suy ra bởi trình biên dịch hoặc để cấu trúc lại chương trình để bạn không cần khả năng của loại dẫn xuất hơn, thì hãy làm như vậy. Truyền phát đã được thêm vào ngôn ngữ cho những trường hợp khó khăn và tốn kém để tái cấu trúc chương trình.

Tại sao downcasting được hỗ trợ bởi ngôn ngữ?

C # được phát minh bởi các lập trình viên thực dụng, những người có việc phải làm, cho các lập trình viên thực dụng, những người có việc phải làm. Các nhà thiết kế C # không phải là những người theo chủ nghĩa thuần túy OO. Và hệ thống loại C # không hoàn hảo; bằng cách thiết kế nó đánh giá thấp các hạn chế có thể được đặt trên loại thời gian chạy của một biến.

Ngoài ra, downcasting rất an toàn trong C #. Chúng tôi có một đảm bảo chắc chắn rằng downcast sẽ được xác minh trong thời gian chạy và nếu nó không thể được xác minh thì chương trình sẽ thực hiện đúng và gặp sự cố. Đây là điều tuyệt vời; điều đó có nghĩa là nếu sự hiểu biết đúng 100% về ngữ nghĩa của bạn hóa ra đúng 99,99%, thì chương trình của bạn hoạt động 99,99% thời gian và làm hỏng phần còn lại của thời gian, thay vì hành xử không thể đoán trước và làm hỏng dữ liệu người dùng 0,01% thời gian .

BÀI TẬP: Có ít nhất một cách để tạo ra một downcast trong C # mà không cần sử dụng toán tử cast rõ ràng. Bạn có thể nghĩ về bất kỳ kịch bản như vậy? Vì đây cũng là những mùi mã tiềm năng, bạn nghĩ yếu tố thiết kế nào đã đi vào thiết kế của một tính năng có thể tạo ra sự cố downcast mà không có biểu hiện trong mã?

Xử lý sự kiện thường có chữ ký MethodName(object sender, EventArgs e). Trong một số trường hợp, có thể xử lý sự kiện mà không cần quan tâm đến loại nào sender, hoặc thậm chí không sử dụng sender, nhưng trong các trường hợp khác senderphải chuyển sang loại cụ thể hơn để xử lý sự kiện.

Ví dụ: bạn có thể có hai TextBoxs và bạn muốn sử dụng một đại biểu duy nhất để xử lý một sự kiện từ mỗi người trong số họ. Sau đó, bạn sẽ cần truyền sendertới một TextBoxđể bạn có thể truy cập các thuộc tính cần thiết để xử lý sự kiện:

private void TextBox_TextChanged(object sender, EventArgs e)
{
   TextBox box = (TextBox)sender;
   box.BackColor = string.IsNullOrEmpty(box.Text) ? Color.Red : Color.White;
}

Vâng, trong ví dụ này, bạn có thể tạo lớp con của riêng bạn TextBoxđã thực hiện điều này trong nội bộ. Không phải lúc nào cũng thực tế hoặc có thể, mặc dù.

Bạn cần downcasting khi một cái gì đó cung cấp cho bạn một siêu kiểu và bạn cần xử lý nó khác nhau tùy thuộc vào loại phụ.

decimal value;
Donation d = user.getDonation();
if (d is CashDonation) {
     value = ((CashDonation)d).getValue();
}
if (d is ItemDonation) {
     value = itemValueEstimator.estimateValueOf(((ItemDonation)d).getItem());
}
System.out.println("Thank you for your generous donation of $" + value);

Không, điều này không có mùi. Trong một thế giới hoàn hảo Donationsẽ có một phương thức trừu tượng getValuevà mỗi kiểu con thực hiện sẽ có một cách thực hiện phù hợp.

Nhưng điều gì sẽ xảy ra nếu các lớp này đến từ thư viện mà bạn không thể hoặc không muốn thay đổi? Sau đó, không có lựa chọn khác.

Để thêm vào câu trả lời của Eric Lippert vì tôi không thể bình luận ...

Bạn thường có thể tránh bị hạ thấp bằng cách cấu trúc lại API để sử dụng thuốc generic. Nhưng thuốc generic không được thêm vào ngôn ngữ cho đến phiên bản 2.0 . Vì vậy, ngay cả khi mã của riêng bạn không cần hỗ trợ các phiên bản ngôn ngữ cổ, bạn có thể thấy mình sử dụng các lớp kế thừa không được tham số hóa. Ví dụ, một số lớp có thể được định nghĩa để mang một trọng tải loại Object, mà bạn buộc phải chuyển sang loại mà bạn biết nó thực sự là.

Có một sự đánh đổi giữa các ngôn ngữ gõ tĩnh và động. Gõ tĩnh cung cấp cho trình biên dịch rất nhiều thông tin để có thể đảm bảo khá mạnh mẽ về sự an toàn của (các phần của) chương trình. Tuy nhiên, điều này phải trả giá vì bạn không chỉ cần biết rằng chương trình của mình là đúng mà còn phải viết mã phù hợp để thuyết phục trình biên dịch rằng đây là trường hợp. Nói cách khác, đưa ra yêu sách dễ hơn là chứng minh chúng.

Có các cấu trúc "không an toàn" giúp bạn thực hiện các xác nhận chưa được chứng minh cho trình biên dịch. Ví dụ: các cuộc gọi vô điều kiện Nullable.Value, các chương trình truyền phát vô điều kiện, dynamiccác đối tượng, v.v. Chúng cho phép bạn xác nhận một yêu cầu ("Tôi khẳng định rằng đối tượng đó alà một String, nếu tôi sai, ném InvalidCastException") mà không cần phải chứng minh. Điều này có thể hữu ích trong trường hợp chứng minh nó khó hơn đáng kể.

Lạm dụng điều này là rủi ro, đó chính xác là lý do tại sao ký hiệu downcast rõ ràng tồn tại và là bắt buộc; đó là muối cú pháp nhằm thu hút sự chú ý vào một hoạt động không an toàn. Ngôn ngữ có thể đã được thực hiện với việc hạ thấp ngầm định (trong đó loại suy ra không rõ ràng), nhưng điều đó sẽ che giấu hoạt động không an toàn này, điều không mong muốn.

Downcasting được coi là xấu vì một vài lý do. Chủ yếu tôi nghĩ bởi vì nó chống OOP.

OOP sẽ thực sự thích nó nếu bạn chưa bao giờ phải thất vọng vì '' raison-d'etre '' của nó là đa hình có nghĩa là bạn không phải đi

if(object is X)
{
    //do the thing we do with X's
}
else
{
    //of the thing we do with Y's
}

bạn chỉ cần làm

x.DoThing()

và mã tự động làm điều kỳ diệu.

Có một số lý do 'khó' không hạ thấp:

• Trong C ++ thì chậm.
• Bạn gặp lỗi thời gian chạy nếu bạn chọn sai loại.

Nhưng sự thay thế cho việc downcasting trong một số tình huống có thể khá xấu xí.

Ví dụ cổ điển là xử lý tin nhắn, trong đó bạn không muốn thêm chức năng xử lý vào đối tượng, nhưng giữ nó trong bộ xử lý tin nhắn. Sau đó tôi có một tấn MessageBaseClasstrong một mảng để xử lý, nhưng tôi cũng cần mỗi loại theo kiểu con để xử lý chính xác.

Bạn có thể sử dụng Double Dispatch để giải quyết vấn đề ( https://en.wikipedia.org/wiki/Double_dispatch ) ... Nhưng điều đó cũng có vấn đề của nó. Hoặc bạn chỉ có thể downcast cho một số mã đơn giản có nguy cơ của những lý do khó khăn.

Nhưng đây là trước khi Generics được phát minh. Bây giờ bạn có thể tránh downcasting bằng cách cung cấp một loại trong đó các chi tiết được chỉ định sau.

MessageProccesor<T> có thể thay đổi các tham số phương thức và trả về giá trị theo loại đã chỉ định nhưng vẫn cung cấp chức năng chung

Tất nhiên không ai bắt buộc bạn phải viết mã OOP và có rất nhiều tính năng ngôn ngữ được cung cấp nhưng không được chấp nhận, chẳng hạn như sự phản chiếu.

Ngoài tất cả những gì đã nói trước đó, hãy tưởng tượng một thuộc tính Tag thuộc loại đối tượng. Nó cung cấp một cách để bạn lưu trữ một đối tượng bạn chọn trong một đối tượng khác để sử dụng sau này khi bạn cần. Bạn cần downcast tài sản này.

Nói chung, không sử dụng một cái gì đó cho đến ngày hôm nay không phải lúc nào cũng là một dấu hiệu của một cái gì đó vô dụng ;-)

Việc sử dụng phổ biến nhất của downcasting trong công việc của tôi là do một số kẻ ngốc phá vỡ nguyên tắc Thay thế của Liskov.

Hãy tưởng tượng có một giao diện trong một số lib của bên thứ ba.

public interface Foo
{
     void SayHello();
     void SayGoodbye();
 }

Và 2 lớp thực hiện nó. Barvà Qux. Barcư xử tốt

public class Bar
{
    void SayHello()
    {
        Console.WriteLine(“Bar says hello.”);
    }
    void SayGoodbye()
    {
         Console.WriteLine(“Bar says goodbye”);
    }
}

Nhưng Quxcư xử không tốt.

public class Qux
{
    void SayHello()
    {
        Console.WriteLine(“Qux says hello.”);
    }
    void SayGoodbye()
    {
        throw new NotImplementedException();
    }
}

Chà ... bây giờ tôi không có lựa chọn nào khác. Tôi phải gõ kiểm tra và (có thể) downcast để tránh việc chương trình của tôi bị dừng.

Một ví dụ thực tế khác là WPF's VisualTreeHelper. Nó sử dụng downcast để truyền DependencyObjecttới Visualvà Visual3D. Ví dụ: VisualTreeHelper.GetParent . Tình trạng downcast xảy ra trong VisualTreeUtils.AsVisualHelper :

private static bool AsVisualHelper(DependencyObject element, out Visual visual, out Visual3D visual3D)
{
    Visual elementAsVisual = element as Visual;

    if (elementAsVisual != null)
    {
        visual = elementAsVisual;
        visual3D = null;
        return true;
    }

    Visual3D elementAsVisual3D = element as Visual3D;

    if (elementAsVisual3D != null)
    {
        visual = null;
        visual3D = elementAsVisual3D;
        return true;
    }            

    visual = null;
    visual3D = null;
    return false;
}