Có phải Cha mẹ là x = new Child (); Thay vì của Child Child x = new Child (); Một cách thực hành tồi nếu chúng ta có thể sử dụng cái sau?

Ví dụ, tôi đã thấy một số mã tạo ra một đoạn như thế này:

Fragment myFragment=new MyFragment();

trong đó khai báo một biến là Fragment thay vì MyFragment, mà MyFragment là một lớp con của Fragment. Tôi không bão hòa dòng mã này vì tôi nghĩ mã này phải là:

MyFragment myFragment=new MyFragment();

cái nào cụ thể hơn, điều đó có đúng không?

Hoặc trong việc khái quát hóa câu hỏi, có phải là sử dụng không tốt:

Parent x=new Child();

thay vì

Child x=new Child();

Nếu chúng ta có thể thay đổi cái trước thành cái sau mà không có lỗi biên dịch?

Nó phụ thuộc vào bối cảnh, nhưng tôi cho rằng bạn nên khai báo loại trừu tượng nhất có thể. Bằng cách đó, mã của bạn sẽ càng chung chung càng tốt và không phụ thuộc vào các chi tiết không liên quan.

Một ví dụ sẽ có một LinkedListvà ArrayListcả hai đều đi xuống List. Nếu mã sẽ hoạt động tốt như nhau với bất kỳ loại danh sách nào thì không có lý do gì để tùy tiện giới hạn nó ở một trong các lớp con.

Câu trả lời của JacquesB là chính xác, mặc dù hơi trừu tượng. Hãy để tôi nhấn mạnh một số khía cạnh rõ ràng hơn:

Trong đoạn mã của bạn, bạn sử dụng newtừ khóa một cách rõ ràng và có lẽ bạn muốn tiếp tục với các bước khởi tạo tiếp theo có khả năng cụ thể cho loại cụ thể: sau đó bạn cần khai báo biến với loại cụ thể đó.

Tình huống sẽ khác khi bạn lấy vật phẩm đó từ nơi khác, vd IFragment fragment = SomeFactory.GiveMeFragments(...);. Ở đây, nhà máy thường trả về loại trừu tượng nhất có thể và mã hướng xuống không nên phụ thuộc vào chi tiết triển khai.

Có sự khác biệt hiệu suất tiềm năng.

Nếu lớp dẫn xuất được niêm phong, thì trình biên dịch có thể nội tuyến và tối ưu hóa hoặc loại bỏ những gì sẽ là các cuộc gọi ảo. Vì vậy, có thể có một sự khác biệt hiệu suất đáng kể.

Ví dụ: ToStringlà một cuộc gọi ảo, nhưng Stringđược niêm phong. Bật String, ToStringlà một lệnh không hoạt động, vì vậy nếu bạn khai báo objectđó là một cuộc gọi ảo, nếu bạn khai báo Stringtrình biên dịch thì không có lớp dẫn xuất nào ghi đè phương thức vì lớp này được niêm phong, vì vậy đó là không có op. Cân nhắc tương tự áp dụng cho ArrayListvs LinkedList.

Do đó, nếu bạn biết loại cụ thể của đối tượng, (và không có lý do đóng gói để che giấu nó), bạn nên khai báo là loại đó. Vì bạn vừa tạo đối tượng, bạn biết loại bê tông.

Sự khác biệt chính là mức độ truy cập cần thiết. Và mọi câu trả lời hay về sự trừu tượng đều liên quan đến động vật, hoặc tôi được kể như vậy.

Hãy để chúng tôi cho rằng bạn có một vài động vật - Cat Birdvà Dog. Bây giờ, những con vật này có một vài hành vi phổ biến - move(), eat(), và speak(). Tất cả chúng đều ăn khác nhau và nói khác nhau, nhưng nếu tôi cần con vật của mình ăn hoặc nói thì tôi không thực sự quan tâm đến cách chúng làm điều đó.

Nhưng đôi khi tôi làm. Tôi chưa bao giờ chăm chỉ một con mèo bảo vệ hay một con chim bảo vệ, nhưng tôi có một con chó bảo vệ. Vì vậy, khi ai đó đột nhập vào nhà tôi, tôi không thể chỉ dựa vào nói để hù dọa kẻ xâm nhập. Tôi thực sự cần con chó của tôi sủa - điều này khác với tiếng nói của nó, nó chỉ là một sự giả mạo.

Vì vậy, trong mã yêu cầu một kẻ xâm nhập tôi thực sự cần phải làm Dog fido = getDog(); fido.barkMenancingly();

Nhưng hầu hết thời gian, tôi có thể vui vẻ có bất kỳ động vật nào thực hiện các thủ thuật mà chúng giả vờ, kêu meo meo hoặc tweet để đối xử. Animal pet = getAnimal(); pet.speak();

Vì vậy, để cụ thể hơn, ArrayList có một số phương thức Listkhông. Đáng chú ý là trimToSize(). Bây giờ, trong 99% trường hợp, chúng tôi không quan tâm đến điều này. Điều Listnày gần như không bao giờ đủ lớn để chúng ta quan tâm. Nhưng có những lúc nó là. Vì vậy, đôi khi, chúng ta phải đặc biệt yêu cầu ArrayListthực hiện trimToSize()và làm cho mảng sao lưu của nó nhỏ hơn.

Lưu ý rằng điều này không phải được thực hiện khi xây dựng - nó có thể được thực hiện thông qua phương thức trả lại hoặc thậm chí là diễn viên nếu chúng tôi hoàn toàn chắc chắn.

Nói chung, bạn nên sử dụng

var x = new Child(); // C#

hoặc là

auto x = new Child(); // C++

đối với các biến cục bộ trừ khi có một lý do chính đáng để biến có một kiểu khác với những gì nó được khởi tạo.

(Ở đây tôi bỏ qua thực tế là mã C ++ rất có thể sẽ sử dụng một con trỏ thông minh. Có những trường hợp không và không có nhiều hơn một dòng tôi thực sự không thể biết.)

Ý tưởng chung ở đây là với các ngôn ngữ hỗ trợ phát hiện biến tự động của các biến, sử dụng nó giúp mã dễ đọc hơn và thực hiện đúng (nghĩa là hệ thống loại của trình biên dịch có thể tối ưu hóa càng nhiều càng tốt và thay đổi khởi tạo thành mới loại hoạt động tốt nếu hầu hết trừu tượng đã được sử dụng).

Tốt vì nó dễ hiểu và dễ sửa đổi mã này:

var x = new Child(); 
x.DoSomething();

Tốt vì nó truyền đạt ý định:

Parent x = new Child(); 
x.DoSomething(); 

Ok, bởi vì nó phổ biến và dễ hiểu:

Child x = new Child(); 
x.DoSomething(); 

Tùy chọn duy nhất thực sự xấu là sử dụng Parentnếu chỉ Childcó một phương thức DoSomething(). Thật tệ vì nó truyền đạt ý định sai:

Parent x = new Child(); 
(x as Child).DoSomething(); // DON'T DO THIS! IF YOU WANT x AS CHILD, STORE x AS CHILD

Bây giờ chúng ta hãy giải thích thêm một chút về trường hợp câu hỏi hỏi cụ thể về:

Parent x = new Child(); 
x.DoSomething(); 

Chúng ta hãy định dạng khác, bằng cách thực hiện một nửa cuộc gọi hàm:

WhichType x = new Child(); 
FunctionCall(x);

void FunctionCall(WhichType x)
    x.DoSomething(); 

Điều này có thể được rút ngắn thành:

FunctionCall(new Child());

void FunctionCall(WhichType x)
    x.DoSomething();

Ở đây, tôi cho rằng nó được chấp nhận rộng rãi WhichTypenên là loại cơ bản / trừu tượng nhất cho phép chức năng hoạt động (trừ khi có những lo ngại về hiệu suất). Trong trường hợp này, loại thích hợp sẽ là một trong hai Parenthoặc một cái gì đó Parentxuất phát từ.

Dòng lý luận này giải thích tại sao sử dụng loại Parentnày là một lựa chọn tốt, nhưng nó không đi vào thời tiết, các lựa chọn khác là xấu (chúng không phải là).

tl; dr - Sử dụngChildhơnParentlà thích hợp hơn trong phạm vi địa phương. Nó không chỉ giúp dễ đọc mà còn cần đảm bảo rằng độ phân giải phương thức quá tải hoạt động đúng và giúp cho phép biên dịch hiệu quả.

Trong phạm vi địa phương,

Parent obj = new Child();  // Works
Child  obj = new Child();  // Better
var    obj = new Child();  // Best

Về mặt khái niệm, đó là về việc duy trì thông tin loại nhất có thể. Nếu chúng tôi hạ cấp xuống Parent, về cơ bản, chúng tôi chỉ loại bỏ thông tin loại có thể hữu ích.

Giữ lại thông tin loại hoàn chỉnh có bốn ưu điểm chính:

1. Cung cấp thêm thông tin cho trình biên dịch.
2. Cung cấp thêm thông tin cho người đọc.
3. Mã sạch hơn, chuẩn hơn.
4. Làm cho logic chương trình trở nên đột biến hơn.

Ưu điểm 1: Thêm thông tin cho trình biên dịch

Loại rõ ràng được sử dụng trong độ phân giải phương thức quá tải và tối ưu hóa.

Ví dụ: Độ phân giải phương thức quá tải

main()
{
    Parent parent = new Child();
    foo(parent);

    Child  child  = new Child();
    foo(child);
}
foo(Parent arg) { /* ... */ }  // More general
foo(Child  arg) { /* ... */ }  // Case-specific optimizations

Trong ví dụ trên, cả hai foo()cuộc gọi đều hoạt động , nhưng trong một trường hợp, chúng ta có được độ phân giải phương thức quá tải tốt hơn.

Ví dụ: Tối ưu hóa trình biên dịch

main()
{
    Parent parent = new Child();
    var x = parent.Foo();

    Child  child  = new Child();
    var y = child .Foo();
}
class Parent
{
    virtual         int Foo() { return 1; }
}
class Child : Parent
{
    sealed override int Foo() { return 2; }
}

Trong ví dụ trên, cả hai .Foo()cuộc gọi cuối cùng đều gọi cùng một overridephương thức trả về 2. Chỉ trong trường hợp đầu tiên, có một phương thức tra cứu ảo để tìm phương thức đúng; tra cứu phương thức ảo này không cần thiết trong trường hợp thứ hai kể từ phương thức đó sealed.

Tín dụng cho @Ben người đã cung cấp một ví dụ tương tự trong câu trả lời của mình .

Ưu điểm 2: Thêm thông tin cho người đọc

Biết loại chính xác, nghĩa là Child, cung cấp thêm thông tin cho bất kỳ ai đang đọc mã, giúp dễ dàng hơn để xem chương trình đang làm gì.

Chắc chắn, có lẽ nó không quan trọng với mã thực tế vì cả hai parent.Foo();và child.Foo();có ý nghĩa, nhưng đối với một người nào đó nhìn thấy mã cho lần đầu tiên, biết thêm thông tin là chỉ đơn giản hữu ích.

Ngoài ra, tùy thuộc vào môi trường phát triển của bạn, IDE có thể cung cấp nhiều công cụ và siêu dữ liệu hữu ích Childhơn Parent.

Ưu điểm 3: Mã sạch hơn, chuẩn hơn

Hầu hết các ví dụ mã C # mà tôi đã thấy gần đây sử dụng var, về cơ bản là tốc ký Child.

Parent obj = new Child();  // Sub-optimal
Child  obj = new Child();  // Optimal, but anti-pattern syntax
var    obj = new Child();  // Optimal, clean, patterned syntax "everyone" uses now

Nhìn thấy một vartuyên bố không khai báo chỉ nhìn ra; nếu có một lý do tình huống cho nó, tuyệt vời, nhưng nếu không thì nó có vẻ chống mẫu.

// Clean:
var foo1 = new Person();
var foo2 = new Job();
var foo3 = new Residence();

// Staggered:
Person foo1 = new Person();
Job foo2 = new Job();
Residence foo3 = new Residence();   

Ưu điểm 4: Logic chương trình đột biến hơn cho tạo mẫu

Ba lợi thế đầu tiên là những lợi thế lớn; cái này nhiều tình huống hơn.

Tuy nhiên, đối với những người sử dụng mã như những người khác sử dụng Excel, chúng tôi liên tục thay đổi mã của mình. Có lẽ chúng ta không cần phải gọi một phương thức độc đáo để Childtrong này phiên bản mã, nhưng chúng ta có thể sử dụng lại hoặc làm lại các mã sau.

Ưu điểm của một hệ thống loại mạnh là nó cung cấp cho chúng tôi một số dữ liệu meta nhất định về logic chương trình của chúng tôi, làm cho các khả năng trở nên rõ ràng hơn. Điều này cực kỳ hữu ích trong việc tạo mẫu, vì vậy tốt nhất là giữ nó ở nơi có thể.

Tóm lược

Sử dụng Parentlàm rối quá trình giải quyết phương thức quá tải, ức chế một số tối ưu hóa trình biên dịch, loại bỏ thông tin khỏi đầu đọc và làm cho mã xấu hơn.

Sử dụng varthực sự là con đường để đi. Nó nhanh chóng, gọn gàng, khuôn mẫu và giúp trình biên dịch và IDE thực hiện công việc của họ đúng cách.

Quan trọng : Câu trả lời này là vềParentso vớiChildtrong phạm vi cục bộ của phương thức. Vấn đềParentso vớiChildrất khác nhau đối với kiểu trả về, đối số và trường lớp.

Cho trước parentType foo = new childType1();, mã sẽ được giới hạn trong việc sử dụng các phương thức kiểu cha mẹ trên foo, nhưng sẽ có thể lưu trữ vào foomột tham chiếu đến bất kỳ đối tượng nào có kiểu xuất phát từ - không parentchỉ là các thể hiện của childType1. Nếu childType1ví dụ mới là điều duy nhất foosẽ giữ một tham chiếu, thì có lẽ tốt hơn là khai báo fookiểu của nó là childType1. Mặt khác, nếu foocó thể cần phải giữ các tham chiếu đến các loại khác, việc khai báo nó parentTypesẽ giúp điều đó trở nên khả thi.

Tôi đề nghị sử dụng

Child x = new Child();

thay vì

Parent x = new Child();

Cái sau mất thông tin trong khi cái trước thì không.

Bạn có thể làm mọi thứ với cái trước mà bạn có thể làm với cái sau nhưng không phải ngược lại.

Để xây dựng con trỏ hơn nữa, hãy để bạn có nhiều cấp độ kế thừa.

Base-> DerivedL1->DerivedL2

Và bạn muốn khởi tạo kết quả của new DerivedL2()một biến. Sử dụng một loại cơ sở cho bạn tùy chọn sử dụng Basehoặc DerivedL1.

Bạn có thể dùng

Base x = new DerivedL2();

hoặc là

DerivedL1 x = new DerivedL2();

Tôi không thấy bất kỳ cách logic nào để thích cái này hơn cái kia.

Nếu bạn dùng

DerivedL2 x = new DerivedL2();

không có gì để tranh cãi

Tôi sẽ đề nghị luôn luôn trả về hoặc lưu trữ các biến là loại cụ thể nhất, nhưng chấp nhận các tham số là loại rộng nhất.

Ví dụ

<K, V> LinkedHashMap<K, V> keyValuePairsToMap(List<K> keys, List<V> values) {
   //...
}

Các thông số là List<T>, một loại rất chung chung. ArrayList<T>, LinkedList<T>Và những người khác có thể tất cả được chấp nhận bởi phương pháp này.

Điều quan trọng, loại trả lại là LinkedHashMap<K, V>, không Map<K, V>. Nếu ai đó muốn gán kết quả của phương pháp này cho a Map<K, V>, họ có thể làm điều đó. Nó thông báo rõ ràng rằng kết quả này không chỉ là bản đồ, mà là bản đồ với thứ tự xác định.

Giả sử phương thức này được trả về Map<K, V>. Nếu người gọi muốn a LinkedHashMap<K, V>, họ sẽ phải thực hiện kiểm tra loại, bỏ và xử lý lỗi, điều này thực sự cồng kềnh.