Tại sao việc sử dụng 'trận chung kết' trên một lớp học thực sự rất tệ?

Tôi đang cấu trúc lại một trang web kế thừa PHP OOP.

Tôi rất muốn bắt đầu sử dụng 'trận chung kết' trên các lớp để " make it explicit that the class is currently not extended by anything". Điều này có thể tiết kiệm rất nhiều thời gian nếu tôi đến một lớp học và tôi tự hỏi liệu tôi có thể đổi tên / xóa / sửa đổi một thuộc protectedtính hoặc phương thức hay không. Nếu tôi thực sự muốn mở rộng một lớp, tôi có thể xóa từ khóa cuối cùng để mở khóa .

Tức là nếu tôi đến một lớp học không có lớp con, tôi có thể ghi lại kiến ​​thức đó bằng cách đánh dấu lớp cuối cùng. Lần sau khi tôi đến nó, tôi sẽ không phải tìm kiếm lại cơ sở mã để xem nó có con không. Do đó tiết kiệm thời gian trong quá trình tái cấu trúc.

Tất cả có vẻ như là một ý tưởng tiết kiệm thời gian hợp lý .... nhưng tôi thường đọc rằng các lớp chỉ nên được thực hiện 'cuối cùng' vào những dịp hiếm hoi / đặc biệt.

Có thể nó làm hỏng việc tạo đối tượng Mock hoặc có các tác dụng phụ khác mà tôi không nghĩ tới.

Tôi đang thiếu gì?

Tôi thường đọc rằng các lớp chỉ nên được thực hiện 'cuối cùng' vào những dịp hiếm hoi / đặc biệt.

Bất cứ ai viết đó là sai. Sử dụng finaltự do, không có gì sai với điều đó. Nó ghi nhận rằng một lớp không được thiết kế có tính kế thừa và điều này thường đúng với tất cả các lớp theo mặc định: thiết kế một lớp có thể được kế thừa một cách có ý nghĩa từ nhiều hơn là chỉ xóa một bộ finalxác định; nó cần rất nhiều sự quan tâm

Vì vậy, sử dụng finaltheo mặc định là không có nghĩa là xấu. Trên thực tế, nhiều người đề xuất rằng đây phải là mặc định, ví dụ Jon Skeet .

Có lẽ nó làm hỏng việc tạo đối tượng Mock

Đây thực sự là một cảnh báo, nhưng bạn luôn có thể truy vấn các giao diện nếu bạn cần chế giễu các lớp học của mình. Điều này chắc chắn là vượt trội so với việc làm cho tất cả các lớp mở cho thừa kế chỉ với mục đích chế giễu.

Nếu bạn muốn để lại một lưu ý cho bản thân rằng một lớp không có lớp con, thì bằng mọi cách hãy làm như vậy và sử dụng một nhận xét, đó là những gì họ làm. Từ khóa "cuối cùng" không phải là một nhận xét và sử dụng các từ khóa ngôn ngữ chỉ để báo hiệu điều gì đó cho bạn (và chỉ bạn mới biết ý nghĩa của nó) là một ý tưởng tồi.

Có một bài viết hay về "Khi nào khai báo lớp cuối cùng" . Một vài trích dẫn từ nó:

TL; DR: Làm cho các lớp của bạn luôn luôn final, nếu chúng thực hiện một giao diện và không có phương thức công khai nào khác được định nghĩa

Tại sao tôi phải sử dụng final?

1. Ngăn chặn chuỗi thừa kế lớn của sự diệt vong
2. Thành phần đáng khích lệ
3. Buộc nhà phát triển suy nghĩ về API công khai của người dùng
4. Buộc nhà phát triển thu nhỏ API công khai của đối tượng
5. Một finallớp luôn có thể được mở rộng
6. extends phá vỡ đóng gói
7. Bạn không cần sự linh hoạt đó
8. Bạn được tự do thay đổi mã

Khi nào nên tránh final:

Các lớp cuối cùng chỉ hoạt động hiệu quả theo các giả định sau:

1. Có một sự trừu tượng (giao diện) mà lớp cuối cùng thực hiện
2. Tất cả các API công khai của lớp cuối cùng là một phần của giao diện đó

Nếu một trong hai điều kiện trước này bị thiếu, thì bạn có thể sẽ đạt đến một thời điểm khi bạn sẽ làm cho lớp có thể mở rộng, vì mã của bạn không thực sự dựa vào trừu tượng.

PS Cảm ơn @ocramius đã đọc tuyệt vời!

"Cuối cùng" cho một lớp có nghĩa là: Bạn muốn một lớp con? Hãy tiếp tục, xóa "cuối cùng", lớp con bao nhiêu tùy thích, nhưng đừng phàn nàn với tôi nếu nó không hoạt động. Bạn đang ở một mình.

Khi một lớp có thể được phân lớp, đó là hành vi mà người khác dựa vào, phải được mô tả bằng thuật ngữ trừu tượng mà các lớp con tuân theo. Người gọi phải được viết để mong đợi một số thay đổi. Tài liệu phải được viết cẩn thận; bạn không thể nói với mọi người "nhìn vào mã nguồn" bởi vì mã nguồn chưa có. Đó là tất cả nỗ lực. Nếu tôi không mong đợi rằng một lớp được phân lớp, đó là nỗ lực không cần thiết. "Cuối cùng" nói rõ rằng nỗ lực này đã không được thực hiện và đưa ra cảnh báo công bằng.

Một điều bạn có thể không nghĩ đến là thực tế là BẤT K change sự thay đổi của một lớp có nghĩa là nó phải trải qua thử nghiệm QA mới.

Đừng đánh dấu mọi thứ là cuối cùng trừ khi bạn thực sự, thực sự có ý đó.

Sử dụng 'cuối cùng' sẽ lấy đi sự tự do của những người khác muốn sử dụng mã của bạn.

Nếu mã bạn viết chỉ dành cho bạn và sẽ không bao giờ được phát hành ra công chúng hoặc khách hàng thì bạn có thể làm với mã của mình những gì bạn muốn, tất nhiên. Mặt khác, bạn ngăn người khác xây dựng mã của bạn. Tôi thường xuyên phải làm việc với một API có thể dễ dàng mở rộng cho nhu cầu của mình, nhưng sau đó tôi bị cản trở bởi 'trận chung kết'.

Ngoài ra, thường có mã mà nên tốt hơn không được thực hiện private, nhưng protected. Chắc chắn, privatecó nghĩa là "đóng gói" và ẩn những thứ được coi là chi tiết thực hiện. Nhưng với tư cách là một lập trình viên API, tôi cũng có thể ghi lại thực tế rằng phương pháp đó xyzđược coi là chi tiết triển khai và do đó, có thể bị thay đổi / xóa trong phiên bản tương lai. Vì vậy, tất cả những người sẽ dựa vào mã như vậy bất chấp cảnh báo đang thực hiện nó với rủi ro của riêng mình. Nhưng anh ta thực sự có thể làm điều đó và sử dụng lại mã (hy vọng đã được thử nghiệm) và đưa ra giải pháp nhanh hơn.

Tất nhiên, nếu việc triển khai API là nguồn mở, người ta có thể xóa 'bản cuối cùng' hoặc tạo các phương thức 'được bảo vệ', nhưng hơn là bạn đã thay đổi mã và cần theo dõi các thay đổi của mình dưới dạng các bản vá.

Tuy nhiên, nếu việc triển khai là nguồn đóng, bạn sẽ bị bỏ lại phía sau khi tìm cách khắc phục hoặc trong trường hợp xấu nhất là chuyển sang API khác với ít hạn chế hơn về khả năng tùy chỉnh / mở rộng.

Lưu ý rằng tôi không thấy 'cuối cùng' hoặc 'riêng tư' là xấu, nhưng tôi nghĩ rằng chúng chỉ được sử dụng quá thường xuyên vì lập trình viên không nghĩ về mã của anh ấy về mặt tái sử dụng và mở rộng mã.