Hiển thị tốt hơn () + Ẩn () hoặc SetVisible (hiển thị bool)?

Điều gì là tốt hơn và tại sao? (Từ quan điểm thiết kế giao diện):

a) Có hai Show()và Hide()chức năng

b) Có một SetVisible(bool visible)chức năng

EDIT: Ví dụ một số đối tượng có trạng thái hiển thị và chức năng này được sử dụng để thay đổi nó.

c) Có đủ các ba Show(), Hide(), SetVisible(bool visible)chức năng

Tôi thích SetVisible(bool visible), bởi vì nó cho phép tôi viết mã khách hàng như thế này:

SetVisible(DetermineIfItShouldBeVisible());

thay vì phải viết

if (DetermineIfItShouldBeVisible()) {
    Show();
} else {
    Hide();
}

Cách SetVisibletiếp cận cũng có thể cho phép thực hiện dễ dàng hơn. Ví dụ, nếu một lớp cụ thể cụ thể chỉ ủy thác phương thức cho các lớp tổng hợp của nó, thì SetVisiblecó nghĩa là một phương thức ít hơn để thực hiện.

void ButtonWithALabel::SetVisible(bool visible) {
    myButton.SetVisible(visible);
    myLabel.SetVisible(visible);
}

Tôi không đồng ý với tất cả các áp phích đề xuất nhiều chức năng để làm điều tương tự là một điều tốt. Trong khi ba chức năng thay vì người ta có thể không có vẻ như nhiều sưng lên, hãy nhớ rằng lớp học của bạn có thể sẽ kết thúc với nhiều chức năng như vậy (ví dụ như setEnabled, enable, disable) và do đó phương pháp này sẽ kết thúc với một nhiều giao diện lớp lớn hơn. Hơn nữa, có khả năng bạn sẽ kết thúc với một loạt các chức năng / thuộc tính âm tương tự / bất cứ thứ gì trong lớp của bạn và việc nhân các hàm sẽ làm mờ thêm cái nào đi với cái gì.

Trong các ngôn ngữ hỗ trợ các thuộc tính, chúng nên được ưu tiên nhưng vì cả Java và C ++ đều không làm được, tôi đoán đó là một điểm cần thiết.

Tôi nghĩ setVisible()nên được ưu tiên vì những lý do sau:

1. Rõ ràng chức năng nghịch đảo là gì ngay lập tức. Để đảo ngược setVisible(false)bạn gọi setVisible(true)trong khi ngược lại hide()có thể dễ dàng reveal().
2. Nó đơn giản hơn về mặt lập trình bất cứ khi nào bạn xác định trạng thái cần lấy mã, tức là bạn có thể gọi setVisible(wantToSee)thay vì sử dụng ifcâu lệnh.
3. Khi bạn có nhiều chức năng tương tự, setX()định dạng tổng quát để bạn có thể có một tập hợp các hàm nhất quán trong khi cách tiếp cận được xác định sẽ tạo ra một loạt các chức năng có thể khó xác định nếu bạn không biết bạn đang tìm kiếm điều gì. Tính nhất quán trong API làm cho chúng dễ học và dễ nhớ hơn đáng kể.

Nó phụ thuộc vào những gì hiển thị và ẩn có nghĩa trong bối cảnh. Trước tiên, bạn muốn tìm ra cái nào là "cách chính" của bạn và tập trung vào phát triển nó:

• Những lý do để chọn setVisible(bool)
  • Nó chỉ là một thao tác lật đơn giản hoặc đối tượng của bạn chủ yếu giữ trạng thái
  • Đối tượng của bạn sẽ dành phần lớn thời gian trong khung CRUD
  • Có rất nhiều mã dễ dàng chia sẻ giữa hiển thị và ẩn
• Lý do để chọn show()vàhide()
  • Có một hiệu ứng phụ quan trọng hoặc rất nhiều logic đang được chạy, chẳng hạn như khi đối tượng phải kiểm tra tất cả các thùng chứa của nó để xem trạng thái hiển thị của chúng hoặc kích hoạt hoạt ảnh chuyển tiếp.
  • Đây có phải là một phần của mô hình miền trong đó việc thể hiện ý định là quan trọng

OK, vì vậy bây giờ bạn đã mã hóa lõi "tiêu chuẩn vàng" của nó, bạn cần tìm hiểu xem có đáng để thêm các phương thức tiện lợi mỏng theo kiểu khác hay không, để giúp mọi người sử dụng đối tượng của bạn dễ dàng hơn.

• Thuận tiện setVisible(bool)
  • Cho phép bạn tránh các câu lệnh if có điều kiện tầm thường và chỉ ảnh hưởng đến khả năng hiển thị (ví dụ setVisible(a==b))
  • Có thể được kết nối vào các khung getter / setter nhất định, nếu điều đó đôi khi bạn mong đợi xảy ra
• Thuận tiện show()vàhide()
  • Hữu ích trong một ngôn ngữ với các hàm và hàm gọi lại hạng nhất (ví dụ onSuccess(widget.show))
  • Dễ đọc hơn nhiều với dấu vết ngăn xếp và hồ sơ hiệu suất, vì bạn có thể nhanh chóng xem chương trình đang cố gắng làm gì

TLDR: Tìm ra cái nào là quan trọng nhất, thực hiện nó và sau đó tự hỏi liệu nó có đáng để thêm phong cách khác như các phương pháp tiện lợi mỏng hay không.

Tôi sẽ nói "cả ba".

Show()và Hide()có xu hướng dễ dàng mò mẫm hơn SetVisible(true)và SetVisible(false). Tuy nhiên, khi bạn muốn thiết lập mức độ hiển thị một cách hợp lý, tốt hơn là nên có một phương thức thực hiện boolthay vì xây dựng một ifxung quanh đó bool.

Bạn có thể hỗ trợ cả ba mà không cần nhân đôi logic và bản tóm tắt tối thiểu:

void Show() {
    foo.Show();
    bar.Show();
}

void Hide() {
    foo.Hide();
    bar.Hide();
}

void SetVisible(bool visible) {
    if (visible) {
        Show();
    } else {
        Hide();
    }
}

Ngoài ra, nếu những thứ bạn đang gói có SetVisibleAPI nhiều hơn :

void Show() {
    SetVisible(true);
}

void Hide() {
    SetVisible(false);
}

void SetVisible(bool visible) {
    foo.SetVisible(visible);
    bar.SetVisible(visible);
}

Tôi thích show () và hide (), trên thực tế, mọi phương thức nhận một boolean đều có thể được thay đổi cho hai phương thức tan thể hiện rõ hơn ý định của API. Ví dụ, Robert Martin trong mã sạch khuyến nghị các phương thức thích sử dụng các đối số bằng 0 so với các phương thức với một đối số.

Một lập luận quan trọng khác đối với tôi là khả năng đọc, theo tôi, mã tốt có thể được đọc như văn xuôi, văn xuôi thực sự kỳ lạ của nó giống như "main_window setVisible false" thay vì "main_window ẩn", bạn viết hay nói như vậy một cách bình thường? xây dựng ngôn ngữ trong các chương trình phần mềm khi hoàn toàn có thể sử dụng ngôn ngữ tự nhiên hơn?.

Tôi tin rằng phương thức này càng biểu cảm, càng dễ đọc và do đó, mã sẽ được duy trì. Hãy xem xét hai trường hợp sau:

Trường hợp 1:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  customerPanel.setVisible(customer.isCustomerEnabled());
}

Trường hợp 2:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  //always show customer panel
  customerPanel.setVisible(true);
}

Trong trường hợp đầu tiên, rõ ràng hàm "setVisible" đang làm gì, nhưng nếu bạn muốn đọc nó, bạn sẽ nói:

đặt bảng điều khiển khách hàng hiển thị nếu khách hàng được bật hoặc đặt bảng ẩn nếu khách hàng bị vô hiệu hóa.

Trong khi mô tả nhiều hơn để nói:

• kiểm tra trạng thái của khách hàng:
  • nếu khách hàng được kích hoạt thì hiển thị bảng điều khiển của khách hàng
  • nếu không, hãy giấu nó đi

sẽ thay đổi chức năng "Trường hợp 1" thành như sau:

void showCustomerData(customerId){
  Customer customer = getCustomer(CustomerId);
  if(customer.isCustomerEnabled()){
    customerPanel.Show();
  }
  else{
    customerPanel.Hide();
  }
}

nó tạo ra nhiều mã hơn, nhưng dễ đọc hơn.

Trường hợp thứ hai có một lỗ hổng rõ ràng, đó là, bạn đã biết rằng bạn muốn hiển thị bảng điều khiển, vậy tại sao không sử dụng chức năng "Hiển thị"?

Tôi không nói rằng việc sử dụng "setVisible" là hoàn toàn sai, nhưng nó gây nhầm lẫn khi bạn cố đọc mã không được viết bởi bạn theo thời gian và nó không tuân thủ quy tắc "Một hàm chỉ nên thực hiện một thao tác".

Tôi tin rằng Hide()/ Show()thay thế là hấp dẫn bởi vì nó dễ hiểu những gì đang diễn ra hơn so với SetVisible(true), trong khi có một chức năng duy nhất là thích hợp hơn vì nó tránh được nhiều điều kiện.

Nếu đó là trường hợp thì tôi khuyên bạn nên sử dụng một phép liệt kê làm đầu vào SetVisible, để bạn có được SetVisible(Visibility.Visible)hoặc SetVisible(Visibility.Hidden). Bạn có một chức năng duy nhất bạn có thể đọc ngay hành động đang được thực hiện.

Sử dụng các quy ước đặt tên của Java, bạn sẽ có thể setVisible(Visibility.VISIBLE)hoặc setVisible(Visibility.HIDDEN).

Tôi đồng ý với câu trả lời của Darien, nhưng muốn thêm một quan điểm từ góc độ lập trình viên C #.

Khi tôi thấy mã có nội dung 'setXXX', tôi đã đọc rằng nó nói rằng nó đặt giá trị cho một thứ, tôi không hy vọng điều này sẽ có tác dụng phụ trong việc đó ngoài việc đặt giá trị đó và tôi thực sự mong đợi điều này là bình thường (tức là tôi có thể tiếp tục đặt nó với cùng một giá trị và nó ổn). Nó giống như truy cập vào một lĩnh vực. Nói chung, tôi cũng mong đợi được xem phương thức 'getXXX' cùng với 'setXXX'.

Tôi không biết liệu đây có phải là những gì bạn mong đợi trong Java và C ++ hay không, nhưng đó là những gì tôi mong đợi ở C #, mặc dù trong C # có một bàn tay ngắn cho cái này được gọi là Thuộc tính. Và đây là một số hướng dẫn hay về cách sử dụng Thuộc tính ( http://msdn.microsoft.com/en-us/l Library / ms182181.aspx ).

Với quan điểm này, thì giao diện tôi chọn hoàn toàn phụ thuộc vào nếu có bất kỳ tác dụng phụ nào (ngoài việc thay đổi giá trị trường đó):

Nếu thực hiện hành động có tác dụng phụ, ví dụ: nó hiển thị hộp thoại thì tôi sẽ đi với "Show ()" và "Hide ()".

Nếu nó không có tác dụng phụ, giả sử tôi đang thiết lập mức độ hiển thị của "tiện ích" và một thứ khác biểu hiện tiện ích đó tùy thuộc vào trạng thái của nó thì tôi sẽ sử dụng setVisibility hoặc setIsVisible. (Tôi sẽ không gọi nó là SetVisible).

Trong C # (không chắc chắn về Java), việc áp dụng mẫu quan sát viên là khá phổ biến, trong đó khung UI sẽ lắng nghe các thay đổi đối với các đối tượng và sẽ tự động kết xuất lại UI khi một thuộc tính như Hiển thị thay đổi. Điều đó có nghĩa là việc đặt giá trị bằng cách gọi setIsVisible xuất hiện như thể nó có tác dụng phụ, nhưng theo định nghĩa của tôi thì không. Hợp đồng của widget được thực hiện bằng cách đặt giá trị trường đại diện cho "IsVisible".

Nói cách khác, tôi có thể chuyển đổi mức độ hiển thị của nhãn trên biểu mẫu trước khi biểu mẫu được hiển thị. Tức là nhãn.getIsVisible == true, nhưng hình thức không được hiển thị.

Tôi không thể gọi Hide () khi biểu mẫu không được hiển thị.

Tôi muốn đề xuất một giao diện được sửa đổi một chút:

Show();
Hide();
ToggleVisible();
ToggleVisible(bool visible);

Tên tốt hơn

Các tên phương thức này giúp nhà phát triển quyết định sử dụng phương pháp nào dựa trên những gì cần thực hiện. Trong khi đó SetVisible(bool visible)có thể gây nhầm lẫn cho một nhà phát triển vì nó truyền tải ý nghĩa ngữ nghĩa tương tự như Show()và Hide(), Toggle()ngụ ý sự tồn tại của một điều kiện quyết định hành động. Do đó, nó trở nên trực quan cho nhà phát triển khi sử dụng từng phương thức.

Giảm dự phòng mã

Lợi ích của việc có nhiều phương thức trong giao diện của bạn là nó đơn giản hóa mã gọi. Bạn chỉ có thể phơi bày Show()và Hide(), nhưng:

• Bạn có thể yêu cầu một số loại SetVisible()phương thức riêng tư để thực hiện công việc thực sự đằng sau hậu trường (hoặc viết mã dự phòng cho Show()và Hide()).
• Mã gọi có thể có nhiều khối if / other dự phòng chỉ để chọn phương thức sử dụng. Điều này làm phồng mã theo ý kiến ​​của tôi.
• Nếu tôi là người tiêu dùng, tôi có thể chỉ cần viết hàm bao bọc của riêng mình để thực hiện những gì SetVisible()(hoặc Toggle()) đã làm để tránh phình mã (tôi ghét mã dự phòng). Do đó, sao chép một phương thức có thể đã tồn tại như một phương thức riêng tư trong quá trình thực hiện.

Tôi sẽ đề nghị sử dụng SetVisible(bool)nếu chỉ khi bật chế độ hiển thị hai lần (hiển thị và ẩn lại hoặc ẩn và hiển thị lại) sẽ khiến mọi thứ ở trạng thái cơ bản giống như trước khi thao tác được thực hiện (sẽ ổn nếu hiển thị và ẩn lại một cái gì đó hoặc ngược lại để các đối tượng cần vẽ lại, với điều kiện có thể được dự kiến ​​sẽ xảy ra "tự động"). Nếu việc ẩn và hiển thị một đối tượng sẽ không có tác dụng gì ngoài việc thay đổi một bit trạng thái, thì sẽ có ý nghĩa đối với mã bên ngoài để có một số phương thức chấp nhận tham số hiển thị và việc viết mã đó sẽ được hỗ trợ SetVisible.

Nếu ẩn và hiển thị lại một đối tượng có thể có tác dụng phụ như thay đổi thứ tự Z, thì các hành động đó rất có thể được thực hiện bằng các phương thức riêng biệt. Trong những trường hợp như vậy, tính hữu ích của các phương thức bên ngoài chấp nhận tham số "mức độ hiển thị" sẽ bị hạn chế, và do đó sẽ có rất ít lợi thế để tạo thuận lợi cho chúng. Hơn nữa, một SetVisiblephương pháp sẽ (sai) gợi ý rằng những thay đổi về khả năng hiển thị của các đối tượng có thể được thực hiện mà không có tác dụng phụ.