Có sai không khi sử dụng tham số boolean để xác định giá trị?

Theo Có sai không khi sử dụng tham số boolean để xác định hành vi? , Tôi biết tầm quan trọng của việc tránh sử dụng các tham số boolean để xác định hành vi, ví dụ:

phiên bản gốc

public void setState(boolean flag){
    if(flag){
        a();
    }else{
        b();
    }
    c();
}

phiên bản mới:

public void setStateTrue(){
    a();
    c();
}

public void setStateFalse(){
    b();
    c();
}

Nhưng làm thế nào về trường hợp tham số boolean được sử dụng để xác định giá trị thay vì hành vi? ví dụ:

public void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

Tôi đang cố gắng loại bỏ cờ isHintOn và tạo 2 chức năng riêng biệt:

public void setHintOn(){
    this.layer1.visible=true;
    this.layer2.visible=false;
    this.layer3.visible=true;
}

public void setHintOff(){
    this.layer1.visible=false;
    this.layer2.visible=true;
    this.layer3.visible=false;
}

nhưng phiên bản sửa đổi có vẻ ít bảo trì hơn vì:

1. Nó có nhiều mã hơn phiên bản gốc

2. rõ ràng không thể thấy rằng khả năng hiển thị của layer2 ngược với tùy chọn gợi ý

3. Khi một lớp mới (ví dụ: layer4) được thêm vào, tôi cần thêm

   this.layer4.visible=false;
   

   và

   this.layer4.visible=true;  
   

   thành setHintOn () và setHint Offer ()

Vì vậy, câu hỏi của tôi là, nếu tham số boolean chỉ được sử dụng để xác định các giá trị, nhưng không phải là hành vi (ví dụ: no if-other trên tham số đó), liệu có còn nên loại bỏ tham số boolean đó không?

Thiết kế API nên tập trung vào những gì có thể sử dụng nhất cho một khách hàng của API, từ phía gọi .

Ví dụ: nếu API mới này yêu cầu người gọi viết mã thường xuyên như thế này

if(flag)
    foo.setStateTrue();
else
    foo.setStateFalse();

thì rõ ràng là việc tránh tham số còn tệ hơn việc có API cho phép người gọi viết

 foo.setState(flag);

Phiên bản cũ chỉ tạo ra một vấn đề mà sau đó phải được giải quyết ở phía gọi (và có thể hơn một lần). Điều đó không làm tăng khả năng đọc và bảo trì.

Các bên thực hiện , tuy nhiên, không nên ra lệnh như thế nào vẻ API công cộng thích. Nếu một hàm như setHintvới một tham số cần ít mã hơn khi triển khai, nhưng API theo thuật ngữ setHintOn/ có setHintOffvẻ dễ sử dụng hơn cho máy khách, thì người ta có thể thực hiện theo cách này:

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

Vì vậy, mặc dù API công khai không có tham số boolean, không có logic trùng lặp ở đây, do đó chỉ có một nơi để thay đổi khi có yêu cầu mới (như trong ví dụ về câu hỏi).

Điều này cũng hoạt động theo cách khác: nếu setStatephương thức từ trên cần chuyển đổi giữa hai đoạn mã khác nhau, thì đoạn mã đó có thể được tái cấu trúc thành hai phương thức riêng tư khác nhau. Vì vậy, IMHO không có ý nghĩa gì khi tìm kiếm một tiêu chí để quyết định giữa "một tham số / một phương thức" và "không tham số / hai phương thức" bằng cách nhìn vào bên trong. Tuy nhiên, hãy nhìn vào cách bạn muốn thấy API trong vai trò của người tiêu dùng.

Nếu nghi ngờ, hãy thử sử dụng "phát triển theo hướng kiểm tra" (TDD), điều đó sẽ buộc bạn phải suy nghĩ về API công khai và cách sử dụng nó.

Martin Fowler trích dẫn Kent Beck trong việc đề xuất các setOn() setOff()phương pháp riêng biệt , nhưng cũng nói rằng điều này không nên được coi là bất khả xâm phạm:

Nếu bạn lấy dữ liệu [sic] từ nguồn boolean, chẳng hạn như điều khiển UI hoặc nguồn dữ liệu, tôi muốn có setSwitch(aValue)hơn

if (aValue)
  setOn();
else
  setOff();

Đây là một ví dụ về việc nên viết API để giúp người gọi dễ dàng hơn, vì vậy nếu chúng ta biết người gọi đến từ đâu, chúng ta nên thiết kế API với thông tin đó. Điều này cũng lập luận rằng đôi khi chúng tôi có thể cung cấp cả hai phong cách nếu chúng tôi nhận được người gọi theo cả hai cách.

Một khuyến nghị khác là sử dụng một giá trị liệt kê hoặc loại cờ để cung cấp truevà falsecác tên cụ thể theo ngữ cảnh tốt hơn. Trong ví dụ của bạn, showHintvà hideHintcó thể tốt hơn.

Tôi nghĩ rằng bạn đang trộn hai thứ trong bài viết của mình, API và cách triển khai. Trong cả hai trường hợp tôi không nghĩ có một quy tắc mạnh mẽ mà bạn có thể sử dụng mọi lúc, nhưng bạn nên xem xét hai điều này một cách độc lập (càng nhiều càng tốt).

Hãy bắt đầu với API, cả hai:

public void setHint(boolean isHintOn)

và:

public void setHintOn()
public void setHintOff()

là những lựa chọn thay thế hợp lệ tùy thuộc vào những gì đối tượng của bạn được cung cấp và cách khách hàng của bạn sẽ sử dụng API. Như Doc đã chỉ ra, nếu người dùng của bạn đã có biến Boolean (từ điều khiển UI, hành động người dùng, bên ngoài, API, v.v.) thì tùy chọn đầu tiên có ý nghĩa hơn, nếu không, bạn chỉ buộc thêm một câu lệnh if vào mã của máy khách . Tuy nhiên, nếu ví dụ bạn đang thay đổi gợi ý thành đúng khi bắt đầu một quy trình và thành sai ở cuối thì tùy chọn đầu tiên cung cấp cho bạn một cái gì đó như thế này:

setHint(true)
// Do your process
…
setHint(false)

trong khi tùy chọn thứ hai cung cấp cho bạn điều này:

setHintOn()
// Do your process
…
setHintOff()

IMO nào dễ đọc hơn nhiều, vì vậy tôi sẽ chọn tùy chọn thứ hai trong trường hợp này. Rõ ràng, không có gì ngăn bạn cung cấp cả hai tùy chọn (hoặc nhiều hơn, bạn có thể sử dụng một enum như Graham đã nói nếu điều đó có ý nghĩa hơn chẳng hạn).

Vấn đề là bạn nên chọn API của mình dựa trên những gì đối tượng phải làm và cách khách hàng sẽ sử dụng nó, không dựa trên cách bạn sẽ triển khai nó.

Sau đó, bạn phải chọn cách bạn triển khai API công khai của mình. Giả sử chúng tôi đã chọn các phương thức setHintOnvà setHintOfflàm API công khai của chúng tôi và chúng chia sẻ logic chung này như trong ví dụ của bạn. Bạn có thể dễ dàng trừu tượng logic này thông qua một phương thức riêng tư (mã được sao chép từ Doc):

private void setHint(boolean isHintOn){
    this.layer1.visible=isHintOn;
    this.layer2.visible=!isHintOn;
    this.layer3.visible=isHintOn;
}

public void setHintOn(){
   setHint(true);
}

public void setHintOff(){
   setHint(false);
}

Ngược lại, giả sử chúng tôi đã chọn setHint(boolean isHintOn)API của mình nhưng hãy đảo ngược ví dụ của bạn, vì bất kỳ lý do gì, việc đặt gợi ý Bật hoàn toàn khác với đặt thành Tắt. Trong trường hợp này, chúng tôi có thể thực hiện nó như sau:

public void setHint(boolean isHintOn){
    if(isHintOn){
        // Set it On
    } else {
        // Set it Off
    }    
}

Hoặc thậm chí:

public void setHint(boolean isHintOn){    
    if(isHintOn){
        setHintOn()
    } else {
        setHintOff()
   }    
}

private void setHintOn(){
   // Set it On
}

private void setHintOff(){
   // Set it Off 
}

Vấn đề là, trong cả hai trường hợp, trước tiên, chúng tôi đã chọn API công khai và sau đó điều chỉnh triển khai của chúng tôi để phù hợp với API đã chọn (và các ràng buộc chúng tôi có), chứ không phải theo cách khác.

Nhân tiện, tôi nghĩ điều tương tự cũng áp dụng cho bài đăng bạn liên kết về việc sử dụng tham số boolean để xác định hành vi, tức là bạn nên quyết định dựa trên trường hợp sử dụng cụ thể của mình thay vì một số quy tắc cứng (mặc dù trong trường hợp cụ thể đó thường là điều đúng là phá vỡ nó trong nhiều chức năng).

Điều đầu tiên trước tiên: mã không tự động ít bảo trì hơn, chỉ vì nó dài hơn một chút. Rõ ràng là những gì quan trọng.

Bây giờ, nếu bạn thực sự chỉ đang xử lý dữ liệu, thì cái bạn có là một setter cho thuộc tính boolean. Trong trường hợp đó, bạn có thể chỉ muốn lưu trữ giá trị đó trực tiếp và lấy được mức độ hiển thị của lớp, tức là

bool isBackgroundVisible() {
    return isHintVisible;
}    

bool isContentVisible() {
    return !isHintVisible;
}

^{(Tôi đã lấy tự do để đặt tên thực tế cho các lớp - nếu bạn không có mã này trong mã gốc của mình, tôi sẽ bắt đầu với điều đó)}

Điều này vẫn để lại cho bạn câu hỏi liệu có một setHintVisibility(bool)phương pháp. Cá nhân, tôi khuyên bạn nên thay thế nó bằng một phương thức showHint()và hideHint()- cả hai sẽ thực sự đơn giản và bạn sẽ không phải thay đổi chúng khi bạn thêm các lớp. Tuy nhiên, đó không phải là một sự cắt giảm đúng / sai.

Bây giờ nếu gọi hàm thực sự sẽ thay đổi mức độ hiển thị của các lớp đó, bạn thực sự có hành vi. Trong trường hợp đó, tôi chắc chắn sẽ đề nghị các phương pháp riêng biệt.

Các tham số Boolean là tốt trong ví dụ thứ hai. Như bạn đã tìm ra, các tham số boolean không phải là vấn đề. Đó là chuyển đổi hành vi dựa trên một cờ, đó là vấn đề.

Ví dụ đầu tiên là có vấn đề, bởi vì việc đặt tên chỉ ra một phương thức setter, nhưng việc triển khai dường như là một cái gì đó khác nhau. Vì vậy, bạn có antipotype chuyển đổi hành vi và một phương pháp được đặt tên sai. Nhưng nếu phương thức thực sự là một setter thông thường (không có chuyển đổi hành vi), thì không có vấn đề gì với setState(boolean). Có hai phương pháp, setStateTrue()và setStateFalse()chỉ cần làm phức tạp mọi thứ không có lợi.

Một cách khác để giải quyết vấn đề này là giới thiệu một đối tượng để thể hiện từng gợi ý và để đối tượng chịu trách nhiệm xác định các giá trị boolean liên quan đến gợi ý đó. Bằng cách này, bạn có thể thêm các hoán vị mới thay vì chỉ có hai trạng thái boolean.

Ví dụ: trong Java, bạn có thể làm:

public enum HintState {
    SHOW_HINT(true, false, true),
    HIDE_HINT(false, true, false);

    private HintState(boolean layer1Visible, boolean layer2Visible, boolean layer3Visible) {
         // constructor body and accessors omitted for clarity
    }
}

Và sau đó mã người gọi của bạn sẽ trông như thế này:

setHint(HintState.SHOW_HINT);

Và mã thực hiện của bạn sẽ trông như thế này:

public void setHint(HintState hint) {
    this.layer1Visible = hint.isLayer1Visible();
    this.layer2Visible = hint.isLayer2Visible();
    this.layer3Visible = hint.isLayer3Visible();
}

Điều này giữ cho mã thực hiện và mã người gọi ngắn gọn, để đổi lấy việc xác định một kiểu dữ liệu mới, ánh xạ rõ ràng được đánh máy mạnh, các ý định được đặt tên cho các bộ trạng thái tương ứng. Tôi nghĩ rằng đó là tốt hơn tất cả xung quanh.

Vì vậy, câu hỏi của tôi là, nếu tham số boolean chỉ được sử dụng để xác định các giá trị, nhưng không phải là hành vi (ví dụ: no if-other trên tham số đó), liệu có còn nên loại bỏ tham số boolean đó không?

Khi tôi có nghi ngờ về những điều như vậy. Tôi muốn hình dung ra dấu vết ngăn xếp sẽ như thế nào.

Trong nhiều năm, tôi đã làm việc với một dự án PHP sử dụng cùng chức năng như setter và getter . Nếu bạn chuyển null, nó sẽ trả về giá trị, nếu không thì đặt nó. Thật là kinh khủng khi làm việc với .

Dưới đây là một ví dụ về dấu vết ngăn xếp:

function visible() : line 440
function parent() : line 398
function mode() : line 384
function run() : line 5

Bạn không có ý tưởng về trạng thái nội bộ và nó làm cho việc gỡ lỗi khó khăn hơn. Có một loạt các tác dụng phụ tiêu cực khác, nhưng thử để xem có giá trị trong một tiết tên hàm và rõ ràng khi chức năng thực hiện một single action.

Bây giờ hình ảnh làm việc với theo dõi ngăn xếp cho một hàm có hành vi A hoặc B dựa trên giá trị boolean.

function bar() : line 92
function setVisible() : line 120
function foo() : line 492
function setVisible() : line 120
function run() : line 5

Điều đó thật khó hiểu nếu bạn hỏi tôi. Các setVisibledòng giống nhau mang lại hai đường dẫn khác nhau.

Vì vậy, trở lại câu hỏi của bạn. Hãy thử hình dung dấu vết ngăn xếp sẽ như thế nào, cách nó truyền đạt cho một người những gì đang xảy ra và tự hỏi liệu bạn có đang giúp một người trong tương lai gỡ lỗi mã không.

Dưới đây là một số lời khuyên:

• một tên hàm rõ ràng ngụ ý mà không cần biết các giá trị đối số.
• một chức năng thực hiện một hành động
• tên ngụ ý đột biến hoặc hành vi bất biến
• giải quyết các thách thức gỡ lỗi liên quan đến khả năng sửa lỗi của ngôn ngữ và công cụ.

Đôi khi mã trông quá mức dưới kính hiển vi, nhưng khi bạn quay lại bức tranh lớn hơn, một cách tiếp cận tối giản sẽ khiến nó biến mất. Nếu bạn cần nó nổi bật để bạn có thể duy trì nó. Thêm nhiều chức năng nhỏ có thể cảm thấy quá dài dòng, nhưng nó cải thiện khả năng bảo trì khi được sử dụng rộng rãi trong bối cảnh lớn hơn.

Trong hầu hết mọi trường hợp khi bạn truyền một booleantham số cho một phương thức dưới dạng cờ để thay đổi hành vi của một cái gì đó, bạn nên xem xét một cách rõ ràng và an toàn hơn để làm điều này.

Nếu bạn không làm gì hơn việc sử dụng Enumđại diện cho nhà nước bạn đã cải thiện sự hiểu biết của mã của bạn.

Ví dụ này sử dụng Nodelớp từ JavaFX:

public enum Visiblity
{
    SHOW, HIDE

    public boolean toggleVisibility(@Nonnull final Node node) {
        node.setVisible(!node.isVisible());
    }
}

luôn luôn tốt hơn, cũng giống như tìm thấy trên nhiều JavaFXđối tượng:

public void setVisiblity(final boolean flag);

nhưng tôi nghĩ .setVisible()và .setHidden()là giải pháp tốt nhất cho tình huống cờ là booleanvì nó rõ ràng nhất và ít dài dòng nhất.

trong trường hợp một cái gì đó có nhiều lựa chọn, điều này thậm chí còn quan trọng hơn để làm theo cách này. EnumSettồn tại chỉ vì lý do này.

Ed Mann có một bài đăng blog thực sự tốt về chủ đề này. Tôi đã định diễn giải đúng những gì anh ta nói, vì vậy để không trùng lặp nỗ lực, tôi sẽ chỉ đăng một liên kết đến bài đăng trên blog của anh ta như một phụ lục cho câu trả lời này.

Khi quyết định giữa một cách tiếp cận đối với một số giao diện vượt qua tham số (boolean) so với các phương thức bị quá tải với tham số đã nói, hãy tìm đến các máy khách đang sử dụng.

Nếu tất cả các cách sử dụng sẽ vượt qua các giá trị không đổi (ví dụ: đúng, sai) thì điều đó lập luận cho sự quá tải.

Nếu tất cả các cách sử dụng sẽ vượt qua một giá trị biến thì điều đó lập luận cho phương thức với cách tiếp cận tham số.

Nếu cả hai thái cực đó đều không áp dụng, điều đó có nghĩa là có sự kết hợp giữa các cách sử dụng máy khách, vì vậy bạn phải chọn hỗ trợ cả hai hình thức, hoặc tạo một loại khách hàng để thích ứng với kiểu khác (đối với họ là kiểu không tự nhiên hơn).

Có hai cân nhắc để thiết kế:

• API: giao diện nào bạn trình bày cho người dùng,
• Thực hiện: sự rõ ràng, khả năng bảo trì, vv ...

Họ không nên bị giam cầm.

Nó là hoàn toàn tốt để:

• có nhiều phương thức trong API ủy nhiệm cho một triển khai,
• có một phương thức duy nhất trong công văn API tới nhiều triển khai tùy thuộc vào điều kiện.

Như vậy, bất kỳ đối số nào cố gắng cân bằng chi phí / lợi ích của thiết kế API bằng chi phí / lợi ích của thiết kế triển khai là không rõ ràng và cần được xem xét cẩn thận.

Về phía API

Là một lập trình viên, tôi thường sẽ ưu tiên các API lập trình được. Mã rõ ràng hơn nhiều khi tôi có thể chuyển tiếp một giá trị so với khi tôi cần một câu lệnh if/ switchtrên giá trị để quyết định hàm nào sẽ gọi.

Cái sau có thể là cần thiết nếu mỗi hàm mong đợi các đối số khác nhau.

Trong trường hợp của bạn, do đó, một phương pháp duy nhất setState(type value)có vẻ tốt hơn.

Tuy nhiên , không có gì tồi tệ hơn không tên là true, false, 2, vv ... những giá trị ảo thuật không có ý nghĩa riêng của họ. Tránh ám ảnh nguyên thủy , và nắm lấy gõ mạnh.

Do đó, từ một API POV, tôi muốn : setState(State state).

Về phía thực hiện

Tôi khuyên bạn nên làm bất cứ điều gì dễ dàng hơn.

Nếu phương pháp này đơn giản, tốt nhất nên giữ cùng nhau. Nếu luồng điều khiển bị chập, tốt nhất nên tách nó theo nhiều phương thức, mỗi phương thức xử lý một trường hợp con hoặc một bước của đường ống.

Cuối cùng, xem xét nhóm .

Trong ví dụ của bạn (có thêm khoảng trắng để dễ đọc):

this.layer1.visible = isHintOn;
this.layer2.visible = ! isHintOn;
this.layer3.visible = isHintOn;

Tại sao layer2xô xu hướng? Đây có phải là một tính năng hay là một lỗi?

Có thể có 2 danh sách [layer1, layer3]và [layer2], với một tên rõ ràng cho biết lý do chúng được nhóm lại với nhau, và sau đó lặp lại qua các danh sách đó.

Ví dụ:

for (auto layer : this.mainLayers) { // layer2
    layer.visible = ! isHintOn;
}
for (auto layer : this.hintLayers) { // layer1 and layer3
    layer.visible = isHintOn;
}

Mã nói cho chính nó, rõ ràng tại sao có hai nhóm và hành vi của họ khác nhau.

Riêng setOn() + setOff()với set(flag)câu hỏi vs , tôi sẽ xem xét cẩn thận xem một loại boolean là tốt nhất ở đây. Bạn có chắc chắn sẽ không bao giờ có lựa chọn thứ ba?

Nó có thể đáng để xem xét một enum thay vì boolean. Cùng với việc cho phép mở rộng, điều này cũng khiến cho việc boolean sai cách trở nên khó khăn hơn, ví dụ:

setHint(false)

đấu với

setHint(Visibility::HIDE)

Với enum, việc mở rộng sẽ dễ dàng hơn nhiều khi ai đó quyết định họ muốn có tùy chọn 'nếu cần':

enum class Visibility {
  SHOW,
  HIDE,
  IF_NEEDED // New
}

đấu với

setHint(false)
setHint(true)
setHintAutomaticMode(true) // New

Theo ..., tôi biết tầm quan trọng của việc tránh sử dụng các tham số boolean để xác định hành vi

Tôi sẽ đề nghị đánh giá lại kiến ​​thức này.

Trước hết, tôi không thấy kết luận mà bạn đang đề xuất trong câu hỏi SE mà bạn liên kết. Họ chủ yếu nói về việc chuyển tiếp một tham số qua một số bước của các cuộc gọi phương thức, trong đó nó được đánh giá rất xa trong chuỗi.

Trong ví dụ của bạn, bạn đang đánh giá tham số ngay trong phương thức của mình. Về mặt đó, nó hoàn toàn không khác biệt với bất kỳ loại tham số nào khác.

Nói chung, hoàn toàn không có gì sai khi sử dụng các tham số boolean; và rõ ràng bất kỳ tham số nào sẽ xác định một hành vi, hoặc tại sao bạn sẽ có nó ở nơi đầu tiên?

Xác định câu hỏi

Câu hỏi tiêu đề của bạn là "Có sai với [...] không?" - nhưng bạn có ý gì với "sai"?.

Theo trình biên dịch C # hoặc Java, điều đó không sai. Tôi chắc chắn rằng bạn biết điều đó và đó không phải là những gì bạn đang hỏi. Tôi sợ khác hơn, chúng tôi chỉ có các nlập trình viên n+1ý kiến ​​khác nhau. Câu trả lời này trình bày những gì cuốn sách Clean Code nói về điều này.

Câu trả lời

Clean Code tạo ra một trường hợp mạnh mẽ chống lại các đối số chức năng nói chung:

Luận cứ thì khó. Họ có rất nhiều sức mạnh khái niệm. [...] độc giả của chúng tôi sẽ phải giải thích nó mỗi lần họ nhìn thấy nó.

Một "độc giả" ở đây có thể là người tiêu dùng API. Nó cũng có thể là lập trình viên tiếp theo, người chưa biết mã này làm gì - có thể là bạn trong một tháng. Họ sẽ trải qua 2 chức năng riêng biệt hoặc thông qua 1 chức năng hai lần , một lần giữ truevà một lần falsetrong tâm trí.
Tóm lại, sử dụng càng ít đối số càng tốt .

Trường hợp cụ thể của một đối số cờ sau đó được giải quyết trực tiếp:

Đối số cờ là xấu xí. Truyền boolean vào một chức năng là một thực tế thực sự khủng khiếp. Nó ngay lập tức làm phức tạp chữ ký của phương thức, lớn tiếng tuyên bố rằng chức năng này làm nhiều hơn một điều. Nó làm một điều nếu cờ là đúng và một điều khác nếu cờ là sai!

Để trả lời câu hỏi của bạn trực tiếp:
Theo Clean Code , nên loại bỏ tham số đó.

Thông tin bổ sung:

Ví dụ của bạn khá đơn giản, nhưng thậm chí ở đó bạn có thể thấy sự đơn giản lan truyền đến mã của bạn: Các hàm không tham số chỉ thực hiện các phép gán đơn giản, trong khi chức năng khác phải thực hiện số học boolean để đạt được cùng một mục tiêu. Đó là số học boolean tầm thường trong ví dụ đơn giản này, nhưng có thể khá phức tạp trong một tình huống thực tế.

Tôi đã thấy rất nhiều đối số ở đây rằng bạn nên làm cho nó phụ thuộc vào người dùng API, bởi vì phải làm điều này ở nhiều nơi sẽ là ngu ngốc:

if (isAfterSunset) light.TurnOn();
else light.TurnOff();

Tôi làm đồng ý rằng một cái gì đó không phải là tối ưu đang xảy ra ở đây. Có thể quá rõ ràng để xem, nhưng câu đầu tiên của bạn đang đề cập đến "tầm quan trọng của việc tránh [sic] sử dụng các tham số boolean để xác định hành vi" và đó là cơ sở cho toàn bộ câu hỏi. Tôi không thấy một lý do nào khiến điều đó trở nên tồi tệ để làm dễ dàng hơn cho người dùng API.

Tôi không biết nếu bạn làm thử nghiệm - trong trường hợp đó, cũng xem xét điều này:

Đối số thậm chí còn khó hơn từ quan điểm thử nghiệm. Hãy tưởng tượng sự khó khăn của việc viết tất cả các trường hợp thử nghiệm để đảm bảo rằng tất cả các kết hợp khác nhau của các đối số hoạt động đúng. Nếu không có đối số, đây là chuyện nhỏ.