Từ "Helper" có phải là một tên mã có mùi không?

Question

Có vẻ như chúng ta đang trừu tượng hóa rất nhiều cách logic từ các trang web và tạo ra các lớp "trợ giúp". Đáng buồn thay, các lớp này đều nghe có vẻ giống nhau, ví dụ

ADHelper, (Active Directory) AuthenicationHelper, SharePointHelper

Có phải người khác có một số lượng lớn các lớp học với quy ước đặt tên này?

Answer 1

Tôi muốn nói rằng nó đủ điều kiện như là một mã nguồn, nhưng hãy nhớ rằng mùi mã không nhất thiết phải gây ra sự cố. Đó là điều bạn nên xem xét và sau đó quyết định xem có ổn không. Đã nói rằng cá nhân tôi thấy rằng một cái tên như thế sẽ bổ sung thêm rất ít giá trị và vì nó quá chung chung nên loại này có thể dễ dàng trở thành một nhóm các phương pháp tiện ích không liên quan. I E. một lớp trợ giúp có thể biến thành một Lớp lớn, là một trong số common code smells.

Nếu có thể, tôi khuyên bạn nên tìm tên loại mô tả kỹ hơn các phương pháp làm. Tất nhiên điều này có thể nhắc các lớp trợ giúp bổ sung, nhưng miễn là tên của chúng là hữu ích, tôi không nhớ các con số.

Một thời gian trước, tôi đã xem một lớp có tên là XmlHelper trong quá trình xem xét mã. Nó có một số phương pháp rõ ràng tất cả phải làm với Xml. Tuy nhiên, nó không phải là rõ ràng từ tên loại những gì các phương pháp có chung (ngoài việc liên quan đến Xml). Nó bật ra rằng một số phương pháp đã được định dạng Xml và những người khác đã phân tích cú pháp Xml. Vì vậy, IMO lớp nên được chia thành hai hoặc nhiều phần với tên cụ thể hơn.

Answer 2

Tôi sẽ không nói rằng đó là một mùi mã. Trong ASP.NET MVC nó là khá phổ biến.

Answer 3

Phụ thuộc vào nội dung thực tế của lớp học.

Nếu một số lượng lớn các quy tắc nghiệp vụ/kinh doanh thực tế là trong các lớp trợ giúp, thì tôi sẽ nói có.

Nếu các lớp thực sự chỉ là những người trợ giúp có thể được sử dụng trong các ứng dụng doanh nghiệp khác (tái sử dụng theo nghĩa tuyệt đối của từ - không sao chép rồi tùy chỉnh), thì tôi sẽ nói những người giúp đỡ không phải là một mã .

Answer 4

Như mọi khi, nó phụ thuộc vào ngữ cảnh.

Khi bạn làm việc với API của riêng bạn Tôi chắc chắn sẽ coi đó là một mùi mã, vì FooHelper chỉ ra rằng nó hoạt động trên Foo, nhưng hành vi này rất có thể sẽ thuộc về trực tiếp trên lớp Foo.

Tuy nhiên, khi bạn làm việc với API hiện (ví dụ như các loại trong BCL), bạn không thể thay đổi thực hiện, vì vậy phương pháp khuyến nông trở thành một trong những cách để giải quyết những thiếu sót trong API gốc. Bạn có thể chọn đặt tên các lớp như vậy FooHelper cũng như FooExtension. Nó có mùi hôi như nhau (hay không).

Answer 5

Đó là một điểm thú vị, nếu một từ trở thành 'boilerplate' trong tên thì có lẽ hơi ngớ ngẩn một chút - nếu không hẳn là một mùi thật. Có lẽ bằng cách sử dụng một thư mục 'Helper' và sau đó cho phép nó xuất hiện trong không gian tên giữ nó sử dụng mà không lạm dụng từ?

Application.Helper.SharePoint 
Application.Helper.Authentication 

và vân vân

Answer 6

Trong nhiều trường hợp, tôi sử dụng các lớp học kết thúc với Helper cho các lớp học tĩnh chứa phương pháp khuyến nông. Dường như không có mùi với tôi. Bạn không thể đặt chúng vào một lớp không tĩnh, và bản thân lớp đó không quan trọng, vì vậy Helper là tốt, tôi nghĩ vậy. Người dùng của một lớp như vậy sẽ không thấy tên lớp.

.NET Framework cũng thực hiện điều này (ví dụ: trong lớp LogicalTreeHelper từ WPF, chỉ có một vài phương pháp tĩnh (không mở rộng)).

Tự hỏi xem mã có tốt hơn không nếu mã trong lớp trợ giúp của bạn sẽ được cấu trúc lại thành các lớp "thực", tức là các đối tượng phù hợp với phân cấp lớp của bạn. Mã số có ở một nơi nào đó và nếu bạn không thể tạo ra một lớp/đối tượng nơi nó thực sự thuộc về, như các hàm trợ giúp đơn giản (do đó là "Trình trợ giúp"), bạn sẽ ổn.