Là ghi đè phương pháp bê tông một mùi mã?

Có đúng là các phương pháp bê tông ghi đè là một mùi mã? Bởi vì tôi nghĩ rằng nếu bạn cần ghi đè các phương thức cụ thể:

public class A{
    public void a(){
    }
}

public class B extends A{
    @Override
    public void a(){
    }
}

nó có thể được viết lại như

public interface A{
    public void a();
}

public class ConcreteA implements A{
    public void a();
}

public class B implements A{
    public void a(){
    }
}

và nếu B muốn sử dụng lại a () trong A, nó có thể được viết lại thành:

public class B implements A{
    public ConcreteA concreteA;
    public void a(){
        concreteA.a();
    }
}

mà không yêu cầu kế thừa để ghi đè phương thức, điều đó có đúng không?

Không, nó không phải là một mùi mã.

• Nếu một lớp không phải là cuối cùng, nó cho phép được phân lớp.
• Nếu một phương thức không phải là cuối cùng, nó cho phép được ghi đè.

Nó nằm trong khả năng đáp ứng của từng lớp để xem xét cẩn thận nếu phân lớp là phù hợp và phương thức nào có thể được ghi đè .

Lớp có thể tự định nghĩa hoặc bất kỳ phương thức nào là cuối cùng hoặc có thể đặt các hạn chế (bộ sửa đổi mức độ hiển thị, các hàm tạo có sẵn) về cách thức và vị trí của nó được phân lớp.

Trường hợp thông thường cho các phương thức ghi đè là một triển khai mặc định trong lớp cơ sở có thể được tùy chỉnh hoặc tối ưu hóa trong lớp con (đặc biệt là trong Java 8 với sự xuất hiện của các phương thức mặc định trong các giao diện).

class A {
    public String getDescription(Element e) {
        // return default description for element
    }
}

class B extends A {
    public String getDescription(Element e) {
        // return customized description for element
    }
}

Một thay thế cho hành vi ghi đè là Mẫu chiến lược , trong đó hành vi được trừu tượng hóa như một giao diện và việc triển khai có thể được đặt trong lớp.

interface DescriptionProvider {
    String getDescription(Element e);
}

class A {
    private DescriptionProvider provider=new DefaultDescriptionProvider();

    public final String getDescription(Element e) {
       return provider.getDescription(e);
    }

    public final void setDescriptionProvider(@NotNull DescriptionProvider provider) {
        this.provider=provider;
    }
}

class B extends A {
    public B() {
        setDescriptionProvider(new CustomDescriptionProvider());
    }
}

Có đúng là các phương pháp bê tông ghi đè là một mùi mã?

Vâng, nói chung, ghi đè các phương pháp cụ thể là một mùi mã.

Bởi vì phương thức cơ sở có một hành vi liên quan đến nó mà các nhà phát triển thường tôn trọng, việc thay đổi sẽ dẫn đến lỗi khi việc triển khai của bạn làm điều gì đó khác biệt. Tệ hơn, nếu họ thay đổi hành vi, việc thực hiện đúng trước đây của bạn có thể làm trầm trọng thêm vấn đề. Và nói chung, khá khó để tôn trọng Nguyên tắc thay thế Liskov cho các phương pháp cụ thể không tầm thường.

Bây giờ, có những trường hợp điều này có thể được thực hiện và là tốt. Các phương pháp bán tầm thường có thể được sử dụng một cách an toàn. Các phương thức cơ bản chỉ tồn tại dưới dạng một loại hành vi "mặc định lành mạnh" có nghĩa là quá mức có một số cách sử dụng tốt.

Do đó, điều này có vẻ như là một mùi đối với tôi - đôi khi tốt, thường là xấu, hãy xem để đảm bảo.

nếu bạn cần ghi đè các phương thức cụ thể [...] thì nó có thể được viết lại thành

Nếu nó có thể được viết lại theo cách đó có nghĩa là bạn có quyền kiểm soát cả hai lớp. Nhưng sau đó bạn biết liệu bạn đã thiết kế lớp A có nguồn gốc theo cách này hay không và nếu bạn đã làm, thì đó không phải là mùi mã.

Mặt khác, nếu bạn không có quyền kiểm soát lớp cơ sở, bạn không thể viết lại theo cách đó. Vì vậy, hoặc lớp được thiết kế để có nguồn gốc theo cách này, trong trường hợp chỉ đi trước, nó không phải là mùi mã, hoặc trong trường hợp đó bạn có hai lựa chọn: tìm kiếm một giải pháp khác hoàn toàn, hoặc đi trước , bởi vì làm việc trumps thiết kế tinh khiết.

Trước tiên, hãy để tôi chỉ ra rằng câu hỏi này chỉ có thể áp dụng trong một số hệ thống gõ nhất định. Ví dụ, trong hệ thống gõ cấu trúc và hệ thống gõ Vịt - một lớp chỉ cần có một phương thức có cùng tên và chữ ký sẽ có nghĩa là lớp đó tương thích với kiểu (ít nhất là đối với phương thức cụ thể đó, trong trường hợp gõ Vịt).

Điều này (rõ ràng) rất khác với lĩnh vực của các ngôn ngữ được nhập tĩnh , chẳng hạn như Java, C ++, v.v. Cũng như bản chất của gõ mạnh , như được sử dụng trong cả Java & C ++, cũng như C # và các ngôn ngữ khác.

Tôi đoán bạn đến từ nền Java, nơi các phương thức phải được đánh dấu rõ ràng là cuối cùng nếu người thiết kế hợp đồng dự định chúng không bị ghi đè. Tuy nhiên, trong các ngôn ngữ như C #, ngược lại là mặc định. Các phương thức (không có bất kỳ trang trí, từ khóa đặc biệt nào) "được niêm phong " (phiên bản của C # final) và phải được khai báo rõ ràng như virtualthể chúng được phép ghi đè.

Nếu một API hoặc thư viện đã được thiết kế trong các ngôn ngữ với một phương pháp cụ thể mà là Overridable, sau đó nó phải (ít nhất là trong một số trường hợp (s)) có ý nghĩa cho nó sẽ được ghi đè. Do đó, nó không phải là một mùi mã để ghi đè lên một finalphương thức cụ thể / ảo / không cụ thể.     _{(Tất nhiên, điều này giả định rằng các nhà thiết kế API đang tuân theo các quy ước và đánh dấu là virtual(C #) hoặc đánh dấu là final(Java) các phương thức thích hợp cho những gì họ đang thiết kế.)}

Xem thêm

• Hệ thống kiểu kết cấu
• Vịt gõ
• Gõ tĩnh
• Gõ mạnh
• Nguyên tắc thay thế Liskov

Có nó là bởi vì nó có thể dẫn đến siêu gọi chống mẫu. Nó cũng có thể làm mất mục đích ban đầu của phương pháp, đưa ra các tác dụng phụ (=> lỗi) và làm cho các thử nghiệm thất bại. Bạn sẽ sử dụng một lớp mà các bài kiểm tra đơn vị có màu đỏ (điền)? Tôi sẽ không.

Tôi sẽ đi xa hơn nữa bằng cách nói, mã mùi ban đầu là khi một phương pháp là không abstracthay final. Bởi vì nó cho phép thay đổi (bằng cách ghi đè) hành vi của một thực thể được xây dựng (hành vi này có thể bị mất hoặc thay đổi). Với abstractvà finalý định là không rõ ràng:

• Tóm tắt: bạn phải cung cấp một hành vi
• Cuối cùng: bạn không được phép sửa đổi hành vi

Cách an toàn nhất để thêm hành vi vào một lớp hiện có là những gì ví dụ cuối cùng của bạn cho thấy: sử dụng mẫu trang trí.

public interface A{
    void a();
}

public final class ConcreteA implements A{
    public void a() {
        ...
    }
}

public final class B implements A{
    private final ConcreteA concreteA;
    public void a(){
        //Additionnal behaviour
        concreteA.a();
    }
}