Tôi không hiểu các đối số chống lại quá tải toán tử [đã đóng]

Tôi vừa đọc một trong những bài báo của Joel trong đó anh ấy nói:

Nói chung, tôi phải thừa nhận rằng tôi hơi sợ các tính năng ngôn ngữ che giấu mọi thứ . Khi bạn nhìn thấy mã

i = j * 5;

Ít nhất là trong C bạn biết rằng j đang được nhân với năm và kết quả được lưu trữ trong i.

Nhưng nếu bạn thấy cùng một đoạn mã trong C ++, bạn không biết gì cả. Không có gì. Cách duy nhất để biết những gì thực sự xảy ra trong C ++ là tìm ra loại i và j là gì, thứ gì đó có thể được khai báo ở đâu đó hoàn toàn khác. Đó là bởi vì j có thể thuộc loại đã operator*quá tải và nó làm điều gì đó cực kỳ dí dỏm khi bạn cố gắng nhân nó.

(Nhấn mạnh của tôi.) Sợ các tính năng ngôn ngữ che giấu mọi thứ? Làm thế nào bạn có thể sợ điều đó? Không che giấu những thứ (còn được gọi là trừu tượng ) một trong những ý tưởng chính của lập trình hướng đối tượng? Mỗi khi bạn gọi một phương thức a.foo(b), bạn không biết mình có thể làm gì. Bạn phải tìm ra loại avà loại b, một cái gì đó có thể được khai báo ở đâu đó hoàn toàn khác. Vì vậy, chúng ta có nên loại bỏ lập trình hướng đối tượng, bởi vì nó che giấu quá nhiều thứ từ lập trình viên?

Và làm thế j * 5nào khác với j.multiply(5), mà bạn có thể phải viết bằng ngôn ngữ không hỗ trợ quá tải toán tử? Một lần nữa, bạn sẽ phải tìm ra kiểu jvà nhìn trộm bên trong multiplyphương thức, bởi vì lo và kìa, jcó thể là một loại có một multiplyphương thức làm một cái gì đó rất dí dỏm.

"Muahaha, tôi là một lập trình viên độc ác đặt tên cho một phương thức multiply, nhưng những gì nó thực sự làm là hoàn toàn tối nghĩa và không trực quan và hoàn toàn không có gì để làm với nhiều thứ." Đó có phải là một kịch bản chúng ta phải xem xét khi thiết kế một ngôn ngữ lập trình? Sau đó, chúng ta phải từ bỏ định danh từ các ngôn ngữ lập trình với lý do chúng có thể gây hiểu nhầm!

Nếu bạn muốn biết phương thức làm gì, bạn có thể xem lướt qua tài liệu hoặc xem lén trong quá trình thực hiện. Quá tải toán tử chỉ là đường cú pháp và tôi không thấy nó thay đổi trò chơi như thế nào.

Vui lòng làm sáng tỏ cho tôi.

Trừu tượng 'ẩn mã' để bạn không phải lo lắng về hoạt động bên trong và thường vì vậy bạn không thể thay đổi chúng, nhưng ý định không phải là để ngăn bạn nhìn vào nó. Chúng tôi chỉ đưa ra các giả định về các nhà khai thác và như Joel nói, nó có thể ở bất cứ đâu. Có một tính năng lập trình yêu cầu tất cả các toán tử quá tải được thiết lập ở một vị trí cụ thể có thể giúp tìm thấy nó, nhưng tôi không chắc nó làm cho việc sử dụng nó dễ dàng hơn.

Tôi không thấy làm * làm một cái gì đó không giống với phép nhân bất kỳ tốt hơn một hàm gọi là Get_Some_Data xóa dữ liệu.

IMHO, các tính năng ngôn ngữ như quá tải toán tử cung cấp cho lập trình viên nhiều sức mạnh hơn. Và, như chúng ta đều biết, với sức mạnh to lớn sẽ có trách nhiệm lớn. Các tính năng cung cấp cho bạn nhiều sức mạnh hơn cũng cung cấp cho bạn nhiều cách hơn để tự bắn vào chân mình, và rõ ràng, nên được sử dụng một cách thận trọng.

Ví dụ, nó có ý nghĩa hoàn hảo để quá tải +hoặc *toán tử cho class Matrixhoặc class Complex. Mọi người sẽ ngay lập tức biết ý nghĩa của nó. Mặt khác, với tôi thực tế điều đó +có nghĩa là việc nối các chuỗi không hoàn toàn rõ ràng, mặc dù Java thực hiện điều này như một phần của ngôn ngữ và STL thực hiện để std::stringsử dụng quá tải toán tử.

Một ví dụ điển hình khác khi quá tải toán tử làm cho mã rõ ràng hơn là con trỏ thông minh trong C ++. Bạn muốn các con trỏ thông minh hoạt động giống như các con trỏ thông thường càng nhiều càng tốt, vì vậy nó có ý nghĩa hoàn hảo để làm quá tải các unary *và ->toán tử.

Về bản chất, quá tải toán tử không gì khác hơn là một cách khác để đặt tên cho hàm. Và có một quy tắc để đặt tên hàm: tên phải được mô tả, làm cho nó rõ ràng ngay lập tức những gì hàm làm. Quy tắc chính xác tương tự áp dụng cho quá tải toán tử.

Trong Haskell "+", "-", "*", "/" vv chỉ là các hàm (infix).

Bạn có nên đặt tên hàm infix là "plus" như trong "4 plus 2" không? Tại sao không, nếu bổ sung là những gì chức năng của bạn làm. Bạn có nên đặt tên cho hàm "cộng" của mình "+" không? Tại sao không.

Tôi nghĩ vấn đề với cái gọi là "toán tử" là, chúng hầu hết giống với các phép toán và không có nhiều cách để diễn giải chúng và do đó có nhiều kỳ vọng về cách mà một phương thức / hàm / toán tử đó làm.

EDIT: làm cho quan điểm của tôi rõ ràng hơn

Dựa trên các câu trả lời khác mà tôi đã thấy, tôi chỉ có thể kết luận rằng sự phản đối thực sự đối với quá tải toán tử là mong muốn mã rõ ràng ngay lập tức.

Điều này thật bi thảm vì hai lý do:

1. Thực hiện theo kết luận hợp lý của nó, nguyên tắc rằng mã phải rõ ràng ngay lập tức sẽ khiến tất cả chúng ta vẫn đang mã hóa trong COBOL.
2. Bạn không học từ mã đó là rõ ràng ngay lập tức. Bạn học từ mã có ý nghĩa một khi bạn dành một chút thời gian để suy nghĩ về cách nó hoạt động.

Tôi phần nào đồng ý.

Nếu bạn viết multiply(j,5), jcó thể thuộc loại vô hướng hoặc ma trận, làm cho multiply()phức tạp hơn hay ít hơn, tùy thuộc vào cái gì j. Tuy nhiên, nếu bạn từ bỏ ý tưởng quá tải hoàn toàn, thì chức năng sẽ phải được đặt tên multiply_scalar()hoặc multiply_matrix()điều đó sẽ làm cho nó rõ ràng những gì xảy ra bên dưới.

Có mã nơi nhiều người trong chúng ta thích nó theo một cách và có mã nơi mà hầu hết chúng ta thích nó theo cách khác. Tuy nhiên, hầu hết các mã rơi vào giữa khu vực giữa hai thái cực đó. Những gì bạn thích ở đó phụ thuộc vào nền tảng và sở thích cá nhân của bạn.

Tôi thấy hai vấn đề với quá tải toán tử.

1. Quá tải làm thay đổi ngữ nghĩa của toán tử, ngay cả khi điều đó không được lập trình viên dự định. Ví dụ, khi bạn quá tải &&, ||hoặc ,, bạn mất các điểm chuỗi được ngụ ý bởi các biến thể tích hợp của các toán tử này (cũng như hành vi ngắn mạch của các toán tử logic). Vì lý do này, tốt hơn là không làm quá tải các toán tử này, ngay cả khi ngôn ngữ cho phép.
2. Một số người thấy quá tải nhà điều hành là một tính năng tốt như vậy, họ bắt đầu sử dụng nó ở mọi nơi, ngay cả khi đó không phải là giải pháp thích hợp. Điều này khiến người khác phản ứng quá mức theo hướng khác và cảnh báo chống lại việc sử dụng quá tải nhà điều hành. Tôi không đồng ý với một trong hai nhóm, nhưng hãy xem xét trung gian: Quá tải toán tử nên được sử dụng một cách tiết kiệm và chỉ khi
   • toán tử quá tải có ý nghĩa tự nhiên đối với cả chuyên gia miền và chuyên gia phần mềm. Nếu hai nhóm đó không đồng ý về ý nghĩa tự nhiên của toán tử, đừng quá tải nó.
   • đối với các loại liên quan, không có ý nghĩa tự nhiên cho toán tử và bối cảnh ngay lập tức (tốt nhất là cùng một biểu thức, nhưng không quá một vài dòng) luôn làm rõ ý nghĩa của toán tử. Một ví dụ về thể loại này sẽ operator<<dành cho các luồng.

Dựa trên kinh nghiệm cá nhân của tôi, cách Java cho phép nhiều phương thức, nhưng không làm quá tải toán tử, có nghĩa là bất cứ khi nào bạn nhìn thấy một toán tử bạn đều biết chính xác nó làm gì.

Bạn không cần phải xem liệu có *gọi mã lạ hay không nhưng biết rằng đó là một bội số và nó hoạt động chính xác như cách được định nghĩa bởi Đặc tả ngôn ngữ Java. Điều này có nghĩa là bạn có thể tập trung vào hành vi thực tế thay vì tìm hiểu tất cả các công cụ wicket được xác định bởi lập trình viên.

Nói cách khác, cấm quá tải toán tử là một lợi ích cho người đọc , không phải người viết và do đó làm cho các chương trình dễ bảo trì hơn!

Một sự khác biệt giữa quá tải a * bvà gọi multiply(a,b)là cái sau có thể dễ dàng được grepping cho. Nếu multiplychức năng không bị quá tải cho các loại khác nhau thì bạn có thể tìm hiểu chính xác chức năng sẽ làm gì, mà không phải theo dõi các loại avà b.

Linus Torvalds có một lập luận thú vị về tình trạng quá tải toán tử. Trong một cái gì đó giống như phát triển nhân linux, nơi hầu hết các thay đổi được gửi qua các bản vá qua email, điều quan trọng là các nhà bảo trì có thể hiểu bản vá sẽ làm gì chỉ với một vài dòng ngữ cảnh xung quanh mỗi thay đổi. Nếu các hàm và toán tử không bị quá tải thì bản vá có thể dễ dàng được đọc hơn theo cách độc lập theo ngữ cảnh, vì bạn không phải xem qua tệp đã thay đổi để biết tất cả các loại là gì và kiểm tra các toán tử bị quá tải.

Tôi nghi ngờ nó có một cái gì đó để làm với sự phá vỡ kỳ vọng. Tôi đã quen với C ++, bạn đã quen với hành vi của nhà điều hành không bị ngôn ngữ hoàn toàn sai khiến và bạn sẽ không ngạc nhiên khi một nhà điều hành làm điều gì đó kỳ quặc. Nếu bạn đã quen với các ngôn ngữ không có tính năng đó và sau đó xem mã C ++, bạn sẽ mang theo những kỳ vọng từ các ngôn ngữ khác đó và có thể rất ngạc nhiên khi bạn phát hiện ra rằng một nhà điều hành quá tải làm điều gì đó thú vị.

Cá nhân tôi nghĩ rằng có một sự khác biệt. Khi bạn có thể thay đổi hành vi của cú pháp tích hợp của ngôn ngữ, nó trở nên mờ hơn đối với lý do. Các ngôn ngữ không cho phép lập trình meta về mặt cú pháp ít mạnh mẽ hơn, nhưng về mặt khái niệm thì đơn giản hơn để hiểu.

Tôi nghĩ rằng quá tải toán tử toán học không phải là vấn đề thực sự với quá tải toán tử trong C ++. Tôi nghĩ rằng các toán tử quá tải không nên dựa vào ngữ cảnh của biểu thức (tức là kiểu) là "xấu xa". Ví dụ, quá tải , [ ] ( ) -> ->* new deletehoặc thậm chí là unary *. Bạn có một số kỳ vọng nhất định từ các nhà khai thác không bao giờ thay đổi.

Tôi hoàn toàn hiểu bạn không thích tranh luận của Joel về việc che giấu. Tôi cũng không. Thực sự tốt hơn nhiều khi sử dụng '+' cho những thứ như các loại số tích hợp hoặc cho các loại của riêng bạn như ma trận. Tôi thừa nhận điều này là gọn gàng và thanh lịch để có thể nhân hai ma trận với '*' thay vì '.multiply ()'. Và sau tất cả chúng ta đã có một loại trừu tượng giống nhau trong cả hai trường hợp.

Điều đau lòng ở đây là khả năng đọc mã của bạn. Trong một trường hợp thực tế, không phải trong ví dụ học thuật về nhân ma trận. Đặc biệt là nếu ngôn ngữ của bạn cho phép xác định các toán tử ban đầu không có trong lõi ngôn ngữ =:=. Rất nhiều câu hỏi thêm phát sinh tại thời điểm này. Nhà điều hành chết tiệt đó là về cái gì? Ý tôi là sự ưu tiên của thứ đó là gì? Sự kết hợp là gì? Theo thứ tự nào là a =:= b =:= cthực sự thực hiện?

Đó đã là một đối số chống lại quá tải toán tử. Vẫn không thuyết phục? Kiểm tra các quy tắc ưu tiên đưa bạn không quá 10 giây? Ok, chúng ta hãy đi xa hơn.

Nếu bạn bắt đầu sử dụng ngôn ngữ cho phép quá tải toán tử, ví dụ ngôn ngữ phổ biến có tên bắt đầu bằng 'S', bạn sẽ nhanh chóng biết rằng các nhà thiết kế thư viện thích ghi đè toán tử. Tất nhiên họ được giáo dục tốt, họ tuân theo các thực tiễn tốt nhất (không có sự hoài nghi ở đây) và tất cả các API của họ có ý nghĩa hoàn hảo khi chúng ta xem xét chúng một cách riêng biệt.

Bây giờ hãy tưởng tượng bạn phải sử dụng một vài API sử dụng nhiều toán tử quá tải với nhau trong một đoạn mã. Hoặc thậm chí tốt hơn - bạn phải đọc một số mã kế thừa như thế. Đây là khi các nhà điều hành quá tải thực sự hút. Về cơ bản, nếu có nhiều toán tử quá tải ở một nơi, chúng sẽ sớm bắt đầu trộn lẫn với các ký tự không phải là số alpha khác trong mã chương trình của bạn. Chúng sẽ trộn lẫn với các ký tự không phải là số không thực sự là toán tử mà là một số yếu tố ngữ pháp ngôn ngữ cơ bản hơn xác định những thứ như khối và phạm vi, hình dạng câu lệnh kiểm soát dòng chảy hoặc biểu thị một số điều meta. Bạn sẽ cần đặt kính và di chuyển mắt gần 10 cm với màn hình LCD để hiểu được sự lộn xộn thị giác đó.

Nói chung, tôi tránh sử dụng quá tải toán tử theo những cách không trực quan. Đó là, nếu tôi có một lớp số, quá tải * là chấp nhận được (và được khuyến khích). Tuy nhiên, nếu tôi có một Nhân viên lớp, thì quá tải * sẽ làm gì? Nói cách khác, các toán tử quá tải theo những cách trực quan giúp bạn dễ đọc và dễ hiểu.

Chấp nhận / Khuyến khích:

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

Không thể chấp nhận:

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

Ngoài những gì đã được nói ở đây, còn có một cuộc tranh luận nữa về việc quá tải toán tử. Thật vậy, nếu bạn viết +, đây là một điều hiển nhiên mà bạn muốn nói thêm vào một cái gì đó. Nhưng đây không phải là luôn luôn như vậy.

C ++ tự cung cấp một ví dụ tuyệt vời về trường hợp như vậy. Làm thế nào được stream << 1cho là được đọc? luồng dịch chuyển trái 1? Không rõ ràng chút nào trừ khi bạn biết rõ rằng << trong C ++ cũng ghi vào luồng. Tuy nhiên, nếu thao tác này được thực hiện như một phương thức, không có nhà phát triển lành mạnh nào viết o.leftShift(1), nó sẽ giống như vậy o.write(1).

Điểm mấu chốt là bằng cách làm cho quá tải toán tử không khả dụng, ngôn ngữ làm cho các lập trình viên nghĩ về tên của các hoạt động. Ngay cả khi tên được chọn không hoàn hảo, vẫn khó hiểu sai tên hơn là một dấu hiệu.

So với các phương thức đánh vần, các toán tử ngắn hơn, nhưng chúng cũng không yêu cầu dấu ngoặc đơn. Dấu ngoặc tương đối bất tiện để gõ. Và bạn phải cân bằng chúng. Tổng cộng, bất kỳ cuộc gọi phương thức nào cũng yêu cầu ba ký tự nhiễu đơn giản so với toán tử. Điều này làm cho việc sử dụng các toán tử rất, rất hấp dẫn.
Tại sao người khác muốn điều này : cout << "Hello world"?

Vấn đề với quá tải là, hầu hết các lập trình viên đều lười biếng không thể tin được và hầu hết các lập trình viên không thể đủ khả năng.

Điều khiến các lập trình viên C ++ lạm dụng quá tải toán tử không phải là sự hiện diện của nó, mà là sự thiếu vắng một cách gọn gàng hơn để thực hiện các cuộc gọi phương thức. Và mọi người không chỉ sợ quá tải nhà điều hành vì điều đó là có thể, nhưng bởi vì nó đã được thực hiện.
Lưu ý rằng ví dụ trong Ruby và Scala không ai sợ quá tải toán tử. Ngoài thực tế, việc sử dụng các toán tử không thực sự ngắn hơn các phương thức, một lý do khác là, Ruby giới hạn toán tử quá tải đến mức tối thiểu hợp lý, trong khi Scala cho phép bạn khai báo các toán tử của riêng mình do đó tránh được va chạm tầm thường.

Lý do Toán tử quá tải là đáng sợ, bởi vì có một số lượng lớn các lập trình viên thậm chí sẽ không bao giờ nghĩ rằng điều *đó không có nghĩa đơn giản là "nhân", trong khi một phương pháp như foo.multiply(bar)ít nhất chỉ ra ngay lập tức cho lập trình viên rằng ai đó đã viết một phương pháp nhân tùy chỉnh . Tại thời điểm đó, họ sẽ tự hỏi tại sao và đi điều tra.

Tôi đã làm việc với "lập trình viên giỏi", những người ở vị trí cấp cao sẽ tạo ra các phương thức gọi là "So sánh giá trị" sẽ có 2 đối số và áp dụng các giá trị từ cái này sang cái kia và trả về một giá trị boolean. Hoặc một phương thức gọi là "LoadTheValues" sẽ đi đến cơ sở dữ liệu cho 3 đối tượng khác, lấy giá trị, thực hiện tính toán, sửa đổi thisvà lưu nó vào cơ sở dữ liệu.

Nếu tôi đang làm việc trong một nhóm với những loại lập trình viên đó, tôi sẽ biết ngay để điều tra những thứ họ đã làm việc. Nếu họ làm quá tải một nhà điều hành, tôi không có cách nào để biết rằng họ đã làm điều đó ngoại trừ giả định họ đã làm và đi tìm.

Trong một thế giới hoàn hảo, hoặc một nhóm với các lập trình viên hoàn hảo, quá tải toán tử có lẽ là một công cụ tuyệt vời. Tôi vẫn chưa làm việc với một nhóm lập trình viên hoàn hảo, vì vậy đó là lý do tại sao nó đáng sợ.