Có đủ để các phương thức được phân biệt chỉ bằng tên đối số (không phải kiểu) không?

Là đủ để các phương thức được phân biệt chỉ bằng tên đối số (không phải loại) hay tốt hơn là đặt tên rõ ràng hơn?

Ví dụ T Find<T>(int id)so với T FindById<T>(int id).

Có bất kỳ lý do chính đáng để đặt tên rõ ràng hơn (tức là thêm ById) so với chỉ giữ tên đối số?

Một lý do tôi có thể nghĩ đến là khi chữ ký của các phương thức giống nhau nhưng chúng có ý nghĩa khác nhau.

FindByFirstName(string name) và FindByLastName(string name)

Chắc chắn có một lý do tốt để đặt tên rõ ràng hơn.

Đây không phải là định nghĩa phương thức nên tự giải thích mà là sử dụng phương pháp . Và trong khi findById(string id)và find(string id)cả hai đều tự giải thích, có một sự khác biệt rất lớn giữa findById("BOB")và find("BOB"). Trong trường hợp trước, bạn biết rằng chữ ngẫu nhiên trên thực tế là một Id. Trong trường hợp sau, bạn không chắc chắn - nó thực sự có thể là một tên cụ thể hoặc một cái gì đó hoàn toàn khác.

Ưu điểm của FindById () .

1. Tương lai và cách nhiệt : Nếu bạn bắt đầu với Find(int), và sau đó có thêm các phương pháp khác ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), vv), những người như tôi có xu hướng dành nhiều lứa tuổi tìm kiếm FindById(int). Không thực sự là một vấn đề nếu bạn có thể và sẽ thay đổi Find(int)thành FindById(int)một khi nó trở nên cần thiết - bằng chứng trong tương lai là về những điều này nếu s.

2. Dễ đọc hơn . Findlà hoàn toàn tốt đẹp nếu nhìn cuộc gọi như record = Find(customerId);Tuy FindByIdlà hơi dễ dàng hơn cho việc đọc nếu nó record = FindById(AFunction());.

3. Kiên định . Bạn luôn có thể áp dụng FindByX(int)/ FindByY(int)mẫu ở mọi nơi, nhưng Find(int X)/ Find(int Y)không thể vì chúng xung đột.

Ưu điểm của Tìm ()

• HÔN. Findrất đơn giản và dễ hiểu, và bên cạnh operator[]đó là một trong 2 tên hàm được mong đợi nhất trong ngữ cảnh này. (Một số lựa chọn thay thế phổ biến là get, lookuphoặc fetch, tùy thuộc vào ngữ cảnh).
• Theo nguyên tắc thông thường, nếu bạn có một tên hàm là một từ nổi tiếng duy nhất mô tả chính xác những gì hàm làm, hãy sử dụng nó. Ngay cả khi có một tên nhiều từ dài hơn thì tốt hơn một chút để mô tả chức năng này làm gì. Ví dụ: Độ dài so với NumberOfElements . Có một sự đánh đổi, và nơi để vẽ đường là chủ đề của một cuộc tranh luận đang diễn ra.
• Nói chung là tốt để tránh dư thừa. Nếu chúng ta nhìn vào FindById(int id), chúng ta có thể dễ dàng loại bỏ sự dư thừa bằng cách thay đổi nó Find(int id), nhưng có một sự đánh đổi - chúng ta mất đi một số sự rõ ràng.

Ngoài ra, bạn có thể nhận được những lợi thế của cả hai bằng cách sử dụng Id được gõ mạnh:

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

Triển khai Id<>: Nhập mạnh các giá trị ID trong C #

Nhận xét ở đây, cũng như trong liên kết ở trên, đưa ra nhiều mối quan tâm về Id<Customer>việc tôi muốn giải quyết:

• Mối quan tâm 1: Đó là một sự lạm dụng thuốc generic. CustomerIdvà OrderIDlà các loại khác nhau ( customerId1 = customerId2;=> tốt, customerId1 = orderId1;=> xấu), nhưng cách triển khai của chúng gần giống nhau, vì vậy chúng tôi có thể thực hiện chúng bằng cách sao chép dán hoặc với siêu lập trình. Mặc dù có giá trị trong một cuộc thảo luận về việc phơi bày hoặc che giấu cái chung, nhưng siêu lập trình là những gì khái quát dành cho.
• Mối quan tâm 2: Nó không dừng lại những lỗi đơn giản. / Đây là một giải pháp tìm kiếm vấn đề Vấn đề chính được loại bỏ bằng cách sử dụng Id được gõ mạnh là thứ tự đối số sai trong lệnh gọi DoSomething(int customerId, int orderId, int productId). Id được gõ mạnh cũng ngăn chặn các vấn đề khác, bao gồm cả OP đã hỏi về.
• Mối quan tâm 3: Nó thực sự chỉ che khuất mã. Thật khó để biết nếu một id được tổ chức int aVariable. Thật dễ dàng để nói rằng Id được giữ Id<Customer> aVariablevà thậm chí chúng ta có thể nói rằng đó là Id khách hàng.
• Mối quan tâm 4: Những Id này không có loại mạnh, chỉ là các hàm bao. Stringchỉ là một bao bọc xung quanh byte[]. Gói, hoặc đóng gói, không xung đột với gõ mạnh.
• Mối quan tâm 5: Đó là quá kỹ thuật. Đây là phiên bản tối thiểu, mặc dù tôi cũng khuyên bạn nên thêm operator==và operator!=nếu bạn không muốn chỉ dựa vào Equals:

.

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

Một cách nghĩ khác về điều này là sử dụng loại an toàn của ngôn ngữ.

Bạn có thể thực hiện một phương pháp như:

Find(FirstName name);

Trong đó FirstName là một đối tượng đơn giản bao bọc một chuỗi chứa tên đầu tiên và có nghĩa là không thể nhầm lẫn về phương thức đang làm gì, cũng như trong các đối số mà nó được gọi.

Tôi sẽ bỏ phiếu cho tuyên bố rõ ràng như FindByID .... Phần mềm nên được xây dựng cho Thay đổi. Nó nên được mở và đóng (RẮN). Vì vậy, lớp được mở để thêm phương thức tìm tương tự như giả sử FindByName .. vv

Nhưng FindByID đã bị đóng và việc triển khai của nó là đơn vị được thử nghiệm.

Tôi sẽ không đề xuất các phương thức với các vị từ, những phương thức này tốt ở cấp độ chung. Điều gì xảy ra nếu dựa trên trường (ByID), bạn có phương pháp hoàn chỉnh khác nhau.

Tôi ngạc nhiên không ai đề nghị sử dụng một vị ngữ như sau:

User Find(Predicate<User> predicate)

Với cách tiếp cận này, không chỉ bạn giảm bề mặt API mà còn cung cấp thêm quyền kiểm soát cho người dùng sử dụng nó.

Nếu điều đó là không đủ, bạn luôn có thể mở rộng nó theo nhu cầu của bạn.