Có phải thành phần của người thừa kế thừa kế

Ví dụ, hãy xem xét tôi có một lớp để các lớp khác mở rộng:

public class LoginPage {
    public String userId;
    public String session;
    public boolean checkSessionValid() {
    }
}

và một số lớp con:

public class HomePage extends LoginPage {

}

public class EditInfoPage extends LoginPage {

}

Trên thực tế, lớp con không có bất kỳ phương thức nào để ghi đè, tôi cũng sẽ không truy cập HomePage theo cách chung, tức là: Tôi sẽ không làm điều gì đó như:

for (int i = 0; i < loginPages.length; i++) {
    loginPages[i].doSomething();
}

Tôi chỉ muốn sử dụng lại trang đăng nhập. Nhưng theo https://stackoverflow.com/a/53354 , tôi nên thích sáng tác ở đây vì tôi không cần giao diện LoginPage, vì vậy tôi không sử dụng tính kế thừa ở đây:

public class HomePage {
    public LoginPage loginPage;
}

public class EditInfoPage {
    public LoginPage loginPage;
}

nhưng vấn đề ở đây, ở phiên bản mới, mã:

public LoginPage loginPage;

trùng lặp khi một lớp mới được thêm vào. Và nếu LoginPage cần setter và getter, nhiều mã cần được sao chép:

public LoginPage loginPage;

private LoginPage getLoginPage() {
    return this.loginPage;
}
private void setLoginPage(LoginPage loginPage) {
    this.loginPage = loginPage;
}

Vì vậy, câu hỏi của tôi là, "thành phần trên thừa kế" vi phạm "nguyên tắc khô"?

Er chờ bạn lo lắng rằng lặp đi lặp lại

public LoginPage loginPage;

ở hai nơi vi phạm DRY? Theo logic đó

int x;

bây giờ chỉ có thể tồn tại trong một đối tượng trong toàn bộ cơ sở mã. Thôi nào.

DRY là một điều tốt để ghi nhớ nhưng thôi nào. ngoài ra

... extends LoginPage

đang được nhân đôi trong giải pháp thay thế của bạn, do đó, thậm chí là hậu môn về DRY sẽ không có ý nghĩa về điều này.

Mối quan tâm DRY hợp lệ có xu hướng tập trung vào hành vi giống hệt nhau cần thiết ở nhiều nơi được xác định ở nhiều nơi sao cho nhu cầu thay đổi hành vi này kết thúc đòi hỏi phải thay đổi ở nhiều nơi. Đưa ra quyết định ở một nơi và bạn sẽ chỉ cần thay đổi chúng ở một nơi. Điều đó không có nghĩa là chỉ một đối tượng có thể giữ một tham chiếu đến LoginPage của bạn.

DRY không nên bị theo dõi một cách mù quáng. Nếu bạn đang sao chép vì sao chép và dán dễ dàng hơn là nghĩ ra một phương thức hay tên lớp tốt thì có lẽ bạn đã nhầm.

Nhưng nếu bạn muốn đặt cùng một mã ở một nơi khác vì nơi khác đó chịu trách nhiệm khác nhau và có thể cần phải thay đổi độc lập thì có lẽ nên nới lỏng việc thực thi DRY của bạn và để hành vi giống hệt này có một bản sắc khác . Đó là cùng một kiểu suy nghĩ đi vào việc cấm các con số ma thuật.

DRY không chỉ là về những gì mã trông như thế nào. Đó là về việc không truyền bá các chi tiết của một ý tưởng xung quanh với sự lặp đi lặp lại vô thức buộc các nhà bảo trì phải sửa chữa mọi thứ bằng cách sử dụng sự lặp đi lặp lại không suy nghĩ. Đó là khi bạn cố gắng nói với bản thân rằng sự lặp đi lặp lại không suy nghĩ chỉ là quy ước của bạn rằng mọi thứ đang đi theo một cách tồi tệ thực sự.

Những gì tôi nghĩ rằng bạn đang thực sự cố gắng để phàn nàn về được gọi là mã soạn sẵn. Có, sử dụng thành phần chứ không phải thừa kế yêu cầu mã soạn sẵn. Không có gì được tiếp xúc miễn phí, bạn phải viết mã để lộ nó. Với tính năng nồi hơi đi kèm với tính linh hoạt của trạng thái, khả năng thu hẹp giao diện được hiển thị, để đặt cho mọi thứ các tên khác nhau phù hợp với mức độ trừu tượng của chúng, cảm ứng ol tốt và bạn đang sử dụng những gì bạn cấu thành từ bên ngoài, chứ không phải Bên trong, vì vậy bạn đang đối mặt với giao diện bình thường.

Nhưng vâng, đó là rất nhiều bàn phím gõ thêm. Miễn là tôi có thể ngăn chặn vấn đề yo-yo nảy lên và xuống một chồng thừa kế khi tôi đọc mã đó là giá trị nó.

Bây giờ không phải là tôi từ chối sử dụng thừa kế. Một trong những cách sử dụng yêu thích của tôi là đưa ra ngoại lệ cho các tên mới:

public class MyLoginPageWasNull extends NullPointerException{}

Một sự hiểu lầm phổ biến với nguyên tắc DRY là nó liên quan đến việc không lặp lại các dòng mã. Nguyên tắc DRY là "Mỗi phần kiến ​​thức phải có một đại diện duy nhất, rõ ràng, có thẩm quyền trong một hệ thống" . Đó là về kiến ​​thức, không phải mã.

LoginPagebiết về cách vẽ trang để đăng nhập. Nếu EditInfoPagebiết cách làm điều này thì đó sẽ là một vi phạm. Bao gồm LoginPagethông qua thành phần không phải là vi phạm nguyên tắc DRY.

Nguyên tắc DRY có lẽ là nguyên tắc bị lạm dụng nhiều nhất trong công nghệ phần mềm và nó luôn luôn phải được coi là không phải là nguyên tắc không sao chép mã, mà là nguyên tắc không sao chép kiến ​​thức miền trừu tượng. Trên thực tế, trong nhiều trường hợp nếu bạn áp dụng DRY chính xác thì bạn sẽ sao chép mã và đây không hẳn là một điều xấu.

Câu trả lời ngắn: có, nó làm - với một số mức độ nhỏ, chấp nhận được.

Thoạt nhìn, tính kế thừa đôi khi có thể giúp bạn tiết kiệm một số dòng mã, vì nó có tác dụng nói "lớp tái sử dụng của tôi sẽ chứa tất cả các phương thức và thuộc tính công khai theo cách 1: 1". Vì vậy, nếu có một danh sách 10 phương thức trong một thành phần, người ta không phải lặp lại chúng trong mã trong lớp kế thừa. Khi trong kịch bản thành phần 9 trong số 10 phương thức đó phải được hiển thị công khai thông qua một thành phần sử dụng lại, thì người ta phải viết ra 9 cuộc gọi ủy nhiệm và để cho các cuộc gọi còn lại, không có cách nào khác.

Tại sao điều này được chấp nhận? Nhìn vào các phương thức được sao chép trong một kịch bản thành phần - các phương thức này chỉ ủy thác các cuộc gọi đến giao diện của thành phần, do đó không chứa logic thực sự.

Trọng tâm của nguyên tắc DRY là tránh có hai vị trí trong mã nơi các quy tắc logic giống nhau được mã hóa - bởi vì khi các quy tắc logic này thay đổi, trong mã không DRY, bạn có thể dễ dàng điều chỉnh một trong những vị trí đó và quên đi vị trí kia, trong đó giới thiệu một lỗi.

Nhưng vì các cuộc gọi ủy nhiệm không chứa logic, nên chúng thường không phải là đối tượng của sự thay đổi như vậy, do đó không gây ra vấn đề thực sự khi "thích sáng tác hơn kế thừa". Và ngay cả khi giao diện của thành phần thay đổi, có thể tạo ra thay đổi chính thức ở tất cả các lớp sử dụng thành phần, trong ngôn ngữ được biên dịch, trình biên dịch sẽ cho chúng ta biết khi chúng ta quên thay đổi một trong những người gọi.

Một lưu ý cho ví dụ của bạn: Tôi không biết bạn HomePagevà bạn EditInfoPagetrông như thế nào, nhưng nếu họ có chức năng đăng nhập và HomePage(hoặc một EditInfoPage) là một LoginPage , thì thừa kế có thể là công cụ chính xác ở đây. Một ví dụ ít gây tranh cãi, trong đó bố cục sẽ là công cụ tốt hơn theo cách rõ ràng hơn, có lẽ sẽ làm cho mọi thứ rõ ràng hơn.

Giả sử không HomePagephải EditInfoPagelà một LoginPage, và người ta muốn sử dụng lại cái sau, như bạn đã viết, rất có thể người ta chỉ yêu cầu một số phần của LoginPage, không phải tất cả mọi thứ. Nếu đó là trường hợp, một cách tiếp cận tốt hơn so với sử dụng sáng tác theo cách hiển thị có thể là

• trích phần có thể tái sử dụng LoginPagethành một thành phần của chính nó

• tái sử dụng mà thành phần trong HomePagevà EditInfoPagetheo cùng một cách nó được sử dụng hiện đang nằm trongLoginPage

Theo cách đó, nó thường sẽ trở nên rõ ràng hơn nhiều tại sao và khi thành phần trên thừa kế là cách tiếp cận đúng.