Tại sao các phương thức tĩnh không thể có thể được ghi đè?

Trong câu trả lời cho câu hỏi này , sự đồng thuận chung là các phương thức tĩnh không có nghĩa là bị ghi đè (và do đó, các hàm tĩnh trong C # không thể là ảo hoặc trừu tượng). Tuy nhiên, đây không chỉ là trường hợp trong C #; Java cũng cấm điều này và C ++ dường như cũng không thích điều đó. Tuy nhiên, tôi có thể nghĩ ra nhiều ví dụ về các hàm tĩnh mà tôi muốn ghi đè trong một lớp con (ví dụ: các phương thức xuất xưởng). Trong khi về lý thuyết, có nhiều cách để khắc phục chúng, không ai trong số chúng sạch sẽ hay đơn giản.

Tại sao các hàm tĩnh không được ghi đè?

Với các phương thức tĩnh, không có đối tượng để cung cấp kiểm soát thích hợp của cơ chế ghi đè.

Cơ chế phương thức ảo lớp / thể hiện bình thường cho phép kiểm soát các phần ghi đè được tinh chỉnh như sau: mỗi đối tượng thực là một thể hiện của chính xác một lớp. Lớp đó xác định hành vi của phần ghi đè; nó luôn có được vết nứt đầu tiên tại các phương thức ảo. Sau đó, nó có thể chọn gọi phương thức cha mẹ vào đúng thời điểm để thực hiện. Mỗi phương thức cha mẹ sau đó cũng lần lượt gọi phương thức cha của nó. Điều này dẫn đến một loạt các yêu cầu cha mẹ, thực hiện một trong những khái niệm về việc sử dụng lại mã mà hướng đối tượng được biết đến. (Ở đây, mã cơ sở / siêu lớp đang được sử dụng lại theo cách tương đối phức tạp; một khái niệm trực giao khác về tái sử dụng mã trong OOP chỉ đơn giản là có nhiều đối tượng của cùng một lớp.)

Các lớp cơ sở có thể được sử dụng lại bởi các lớp con khác nhau và mỗi lớp có thể cùng tồn tại thoải mái. Mỗi lớp được sử dụng để khởi tạo các đối tượng ra lệnh cho hành vi của chính nó, hòa bình và đồng thời cùng tồn tại với các đối tượng khác. Máy khách có quyền kiểm soát hành vi nào nó muốn và khi nào bằng cách chọn lớp nào sẽ sử dụng để khởi tạo một đối tượng và truyền cho người khác theo ý muốn.

(Đây không phải là một cơ chế hoàn hảo, vì người ta luôn có thể xác định các khả năng không được hỗ trợ, tất nhiên, đó là lý do tại sao các mẫu như phương pháp nhà máy và tiêm phụ thuộc được đặt lên hàng đầu.)

Vì vậy, nếu chúng ta tạo ra khả năng ghi đè cho thống kê mà không thay đổi bất cứ điều gì khác, chúng ta sẽ gặp khó khăn khi đặt hàng ghi đè. Thật khó để xác định bối cảnh giới hạn cho khả năng áp dụng của ghi đè, vì vậy bạn sẽ có được ghi đè trên toàn cầu thay vì cục bộ hơn như với các đối tượng. Không có đối tượng thể hiện để chuyển đổi hành vi. Vì vậy, nếu ai đó đã gọi phương thức tĩnh đã bị ghi đè bởi một lớp khác, liệu ghi đè có được kiểm soát hay không? Nếu có nhiều phần ghi đè như vậy, ai sẽ kiểm soát trước? thứ hai? Với các đối tượng ghi đè, tất cả các câu hỏi này đều có câu trả lời có ý nghĩa và có lý do, nhưng với số liệu thống kê thì không.

Ghi đè cho thống kê sẽ rất hỗn loạn, và, những việc như thế này đã được thực hiện trước đây.

Ví dụ, Mac OS System 7 và trước đó đã sử dụng cơ chế vá bẫy để mở rộng hệ thống bằng cách kiểm soát các cuộc gọi hệ thống do ứng dụng tạo ra trước hệ điều hành. Bạn có thể nghĩ bảng vá gọi hệ thống như một mảng các con trỏ hàm, giống như một vtable cho các đối tượng thể hiện, ngoại trừ việc nó là một bảng toàn cục duy nhất.

Điều này gây ra sự đau buồn không thể kể xiết cho các lập trình viên vì tính chất không có thứ tự của việc vá bẫy. Bất cứ ai phải vá cái bẫy cuối cùng về cơ bản là chiến thắng, ngay cả khi họ không muốn. Mỗi miếng vá của bẫy sẽ nắm bắt giá trị bẫy trước đó cho một loại khả năng gọi cha mẹ, cực kỳ dễ vỡ. Xóa một bản vá bẫy, giả sử khi bạn không còn cần biết về một cuộc gọi hệ thống bị coi là hình thức xấu vì bạn không thực sự có thông tin cần thiết để xóa bản vá của mình (nếu bạn đã thực hiện, bạn cũng sẽ hủy bỏ mọi bản vá khác đã theo dõi bạn).

Điều này không có nghĩa là không thể tạo ra một cơ chế để ghi đè các số liệu thống kê, nhưng điều tôi có thể muốn làm thay vào đó là biến các trường tĩnh và phương thức tĩnh thành trường đối tượng và phương thức cá thể của siêu dữ liệu, sao cho đối tượng bình thường kỹ thuật định hướng sau đó sẽ áp dụng. Lưu ý rằng có những hệ thống cũng làm điều này: CSE 341: Các lớp và siêu dữ liệu nhỏ ; Xem thêm: Smalltalk tương đương với tĩnh của Java là gì?

Tôi đang cố gắng nói rằng bạn sẽ phải thực hiện một số thiết kế tính năng ngôn ngữ nghiêm túc để làm cho nó hoạt động tốt hơn nữa. Đối với một ví dụ, một cách tiếp cận ngây thơ đã được thực hiện, đi khập khiễng, nhưng rất có vấn đề, và được cho là (tôi sẽ tranh luận) về mặt kiến ​​trúc bị thiếu sót bằng cách cung cấp một sự trừu tượng không đầy đủ và khó sử dụng.

Vào thời điểm bạn hoàn thành thiết kế tính năng ghi đè tĩnh để hoạt động độc đáo, bạn có thể đã phát minh ra một số dạng siêu dữ liệu, đây là phần mở rộng tự nhiên của OOP thành / cho các phương thức dựa trên lớp. Vì vậy, không có lý do gì để không làm điều này - và một số ngôn ngữ thực sự làm. Có lẽ đó chỉ là một chút yêu cầu bên lề mà một số ngôn ngữ chọn không làm.

Ghi đè phụ thuộc vào công văn ảo: bạn sử dụng loại thời gian chạy của thistham số để quyết định phương thức nào sẽ gọi. Một phương thức tĩnh không có thistham số, vì vậy không có gì để gửi đi.

Một số ngôn ngữ, đặc biệt là Delphi và Python, có phạm vi "ở giữa" cho phép thực hiện điều này: các phương thức lớp. Một phương thức lớp không phải là một phương thức cá thể thông thường, nhưng nó cũng không tĩnh; nó nhận được một selftham số (thú vị là cả hai ngôn ngữ đều gọi thistham số self) đó là một tham chiếu đến chính loại đối tượng, chứ không phải là một thể hiện của loại đó. Với giá trị đó, bây giờ bạn có một loại có sẵn để thực hiện công văn ảo.

Thật không may, cả JVM và CLR đều không có gì có thể so sánh được.

Bạn hỏi

Tại sao các hàm tĩnh không được ghi đè?

Tôi hỏi

Tại sao các chức năng bạn muốn ghi đè là tĩnh?

Một số ngôn ngữ nhất định buộc bạn phải bắt đầu chương trình theo phương thức tĩnh. Nhưng sau đó, bạn thực sự có thể giải quyết rất nhiều vấn đề mà không cần bất kỳ phương pháp tĩnh nào nữa.

Một số người thích sử dụng các phương thức tĩnh bất cứ lúc nào không có sự phụ thuộc vào trạng thái trong một đối tượng. Một số người thích sử dụng các phương thức tĩnh để xây dựng các đối tượng khác. Một số người thích tránh các phương thức tĩnh càng nhiều càng tốt.

Không ai trong số những người này là sai.

Nếu bạn cần nó quá mức, chỉ cần dừng ghi nhãn tĩnh. Nothings sẽ phá vỡ vì bạn có một vật thể phi trạng thái bay xung quanh.

Tại sao các phương thức tĩnh không thể có thể được ghi đè?

Đó không phải là một câu hỏi "nên".

"Ghi đè" có nghĩa là "gửi động ". "Phương thức tĩnh" có nghĩa là "gửi tĩnh". Nếu một cái gì đó là tĩnh, nó không thể bị ghi đè. Nếu một cái gì đó có thể được ghi đè, nó không tĩnh.

Câu hỏi của bạn khá giống với câu hỏi: "Tại sao xe ba bánh không thể có bốn bánh?" Các định nghĩa của "ba bánh" là có ba bánh xe. Nếu là xe ba bánh, nó không thể có bốn bánh, nếu có bốn bánh, nó không thể là xe ba bánh. Tương tự như vậy, định nghĩa của "phương thức tĩnh" là nó được gửi tĩnh. Nếu đó là một phương thức tĩnh, nó không thể được gửi đi một cách linh hoạt, nếu nó có thể được gửi đi một cách linh hoạt, nó không thể là một phương thức tĩnh.

Tất nhiên, hoàn toàn có thể có các phương thức lớp có thể được ghi đè. Hoặc, bạn có thể có một ngôn ngữ như Ruby, trong đó các lớp là các đối tượng giống như bất kỳ đối tượng nào khác và do đó có thể có các phương thức cá thể, loại bỏ hoàn toàn nhu cầu về các phương thức lớp hoàn toàn. (Ruby chỉ có một loại phương thức: phương thức cá thể. Nó không có phương thức lớp, phương thức tĩnh, hàm tạo, hàm hoặc thủ tục.)

do đó, các hàm tĩnh trong C # không thể là ảo hoặc trừu tượng

Trong C #, bạn luôn gọi các thành viên tĩnh bằng cách sử dụng lớp, ví dụ BaseClass.StaticMethod(), không baseObject.StaticMethod(). Vì vậy, cuối cùng, nếu bạn đã ChildClasskế thừa từ BaseClassvà childObjectmột thể hiện của ChildClass, bạn sẽ không thể gọi phương thức tĩnh của bạn từ đó childObject. Bạn sẽ luôn cần phải sử dụng rõ ràng lớp thực, vì vậy static virtualchỉ là không có ý nghĩa.

Những gì bạn có thể làm là xác định lại staticphương thức tương tự trong lớp con của bạn và sử dụng newtừ khóa.

class BaseClass {
    public static int StaticMethod() { return 1; }
}

class ChildClass {
    public static new int StaticMethod() { return BaseClass.StaticMethod() + 2; }
}

int result;    
var baseObj = new BaseClass();
var childObj = new ChildClass();

result = BaseClass.StaticMethod();
result = baseObj.StaticMethod(); // DOES NOT COMPILE

result = ChildClass.StaticMethod();
result = childObj.StaticMethod(); // DOES NOT COMPILE

Nếu có thể gọi baseObject.StaticMethod(), thì câu hỏi của bạn sẽ có ý nghĩa.