Tốt hơn là có 2 phương thức với ý nghĩa rõ ràng, hoặc chỉ 1 phương thức sử dụng kép?

Để đơn giản hóa giao diện, tốt hơn là không có getBalance()phương thức? Đi qua 0đến charge(float c);sẽ cho kết quả tương tự:

public class Client {
    private float bal;
    float getBalance() { return bal; }
    float charge(float c) {
        bal -= c;
        return bal;
    }
}

Có thể làm một ghi chú trong javadoc? Hoặc, chỉ để lại cho người dùng lớp để tìm ra cách lấy số dư?

Bạn dường như gợi ý rằng độ phức tạp của một giao diện được đo bằng số lượng phần tử mà nó có (phương thức, trong trường hợp này). Nhiều người sẽ lập luận rằng phải nhớ rằng chargephương thức này có thể được sử dụng để trả về số dư của một Clientsự phức tạp hơn nhiều so với việc có thêm phần tử phụ của getBalancephương thức. Làm cho mọi thứ rõ ràng hơn đơn giản hơn nhiều, đặc biệt là đến mức nó không để lại sự mơ hồ, bất kể số lượng phần tử cao hơn trong giao diện.

Bên cạnh đó, việc gọi charge(0)vi phạm nguyên tắc ít gây ngạc nhiên nhất , còn được gọi là số liệu WTF mỗi phút (từ Clean Code, hình ảnh bên dưới), gây khó khăn cho các thành viên mới của nhóm (hoặc những người hiện tại, sau một thời gian rời xa mã) họ hiểu rằng cuộc gọi thực sự được sử dụng để lấy số dư. Hãy nghĩ về cách các độc giả khác sẽ phản ứng:

Ngoài ra, chữ ký của chargephương thức đi ngược lại các hướng dẫn thực hiện một và chỉ một điều và tách biệt truy vấn lệnh , bởi vì nó làm cho đối tượng thay đổi trạng thái của nó trong khi cũng trả về một giá trị mới.

Nói chung, tôi tin rằng giao diện đơn giản nhất trong trường hợp này sẽ là:

public class Client {
  private float bal;
  float getBalance() { return bal; }
  void charge(float c) { bal -= c; }
}

IMO, thay thế getBalance()bằng charge(0)ứng dụng của bạn không phải là một sự đơn giản hóa. Vâng, đó là ít dòng hơn, nhưng nó làm xáo trộn ý nghĩa của charge()phương thức, điều này có khả năng gây đau đầu xuống dòng khi bạn hoặc người khác cần xem lại mã này.

Mặc dù họ có thể cho cùng một kết quả, nhưng việc lấy số dư của một tài khoản không giống như một khoản phí bằng 0, vì vậy có lẽ tốt nhất là bạn nên tách rời mối quan tâm của mình. Ví dụ: nếu bạn cần sửa đổi charge()để đăng nhập bất cứ khi nào có giao dịch tài khoản, thì bây giờ bạn có vấn đề và dù sao cũng cần phải tách chức năng.

Điều quan trọng cần nhớ là mã của bạn phải tự ghi lại. Khi tôi gọi charge(x), tôi sẽ xbị tính phí. Thông tin về số dư chỉ là thứ yếu. Hơn nữa, tôi có thể không biết cách charge()triển khai khi tôi gọi nó và tôi chắc chắn sẽ không biết nó được triển khai như thế nào vào ngày mai. Ví dụ: xem xét bản cập nhật tiềm năng này trong tương lai để charge():

float charge(float c) {
    lockDownUserAccountUntilChargeClears();
    bal -= c;
    Unlock();
    return bal;
}

Bất ngờ sử dụng charge()để có được sự cân bằng trông không được tốt lắm.

Sử dụng charge(0);để lấy số dư là một ý tưởng tồi: một ngày nào đó, ai đó có thể thêm một số mã vào đó để ghi lại các khoản phí được thực hiện mà không nhận ra việc sử dụng chức năng khác, và sau đó mỗi khi ai đó nhận được số dư, nó sẽ được ghi lại dưới dạng phí. (Có nhiều cách xoay quanh vấn đề này, chẳng hạn như một tuyên bố có điều kiện có nội dung như sau:

if (c > 0) {
    // make and log charge
}
return bal;

nhưng những điều này phụ thuộc vào lập trình viên biết để thực hiện chúng, điều mà anh ta sẽ không làm nếu không rõ ràng ngay lập tức rằng chúng là cần thiết.

Nói tóm lại: đừng dựa vào người dùng hoặc người kế thừa lập trình viên của bạn nhận ra rằng đó charge(0);là cách chính xác để có được số dư, bởi vì trừ khi có tài liệu mà họ được đảm bảo không bỏ lỡ thì thật ra đó là cách đáng sợ nhất để có được sự cân bằng khả thi.

Tôi biết có rất nhiều câu trả lời, nhưng một lý do khác chống lại charge(0)là một lỗi đánh máy đơn giản charge(9)sẽ khiến số dư của khách hàng của bạn giảm đi mỗi khi bạn muốn lấy số dư của họ. Nếu bạn có thử nghiệm đơn vị tốt, bạn có thể giảm thiểu rủi ro đó, nhưng nếu bạn không siêng năng trong mọi cuộc gọi đến chargebạn có thể gặp phải rủi ro này.

Tôi muốn đề cập đến một trường hợp cụ thể trong đó sẽ có ý nghĩa khi có các phương thức ít hơn, đa mục đích hơn: nếu có nhiều đa hình, nghĩa là, nhiều triển khai của giao diện này ; đặc biệt là nếu các triển khai đó nằm trong mã được phát triển riêng mà không thể cập nhật đồng bộ hóa (giao diện được xác định bởi thư viện).

Trong trường hợp đó, đơn giản hóa công việc viết mỗi lần thực hiện có giá trị hơn nhiều so với sự rõ ràng của việc sử dụng nó, bởi vì trước đây tránh được các lỗi vi phạm hợp đồng (hai phương pháp không phù hợp với nhau), trong khi phương pháp sau chỉ làm tổn thương tính dễ đọc, có thể được phục hồi bởi một hàm trợ giúp hoặc phương thức siêu lớp xác định getBalancetheo các điều khoản của charge.

(Đây là một mẫu thiết kế, mà tôi không nhớ tên cụ thể để: xác định giao diện thân thiện với người gọi phức tạp theo giao diện thân thiện với người triển khai tối thiểu. nhưng điều này dường như không phải là một thuật ngữ phổ biến.)

Nếu đây không phải là trường hợp (có một vài triển khai hoặc chính xác một) thì tách biệt các phương thức cho rõ ràng và để cho phép bổ sung đơn giản các hành vi liên quan đến các khoản phí khác không charge(), có ý nghĩa.