Чи достатньо, щоб методи розрізняли лише за назвою аргументу (а не за типом)?

Чи достатньо, щоб методи розрізняли лише за назвою аргументу (а не типом) чи краще називати його більш чітко?

Так , наприклад T Find<T>(int id)проти T FindById<T>(int id).

Чи є якась вагома причина назвати це більш чітко (тобто додавати ById) проти збереження лише імені аргументу?

Я можу подумати, коли підписи методів однакові, але вони мають інше значення.

FindByFirstName(string name) і FindByLastName(string name)

Впевнені, що є вагомі підстави назвати це більш чітко.

Це не в першу чергу бути метод визначення , які повинні бути очевидні, але метод використання . І в той час , findById(string id)і find(string id)обидва очевидні, є величезна різниця між findById("BOB")і find("BOB"). У першому випадку ви знаєте, що випадковий буквал насправді є Id. В останньому випадку ви не впевнені - це насправді може бути дане ім’я або щось інше цілком.

Переваги FindById () .

1. Майбутнє теплоізолюючі : Якщо почати з Find(int), а потім повинні додати інші методи ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), і т.д.), люди , як я , як правило , витрачати віків шукають FindById(int). Не дійсно проблема , якщо ви можете і буде змінюватися , Find(int)щоб , FindById(int)як тільки це стане необхідним - майбутнє коректури про них , якщо с.

2. Легше читати . Findідеально добре, якщо дзвінок виглядає, що record = Find(customerId);все-таки FindByIdтрохи легше для читання, якщо він є record = FindById(AFunction());.

3. Послідовність . Ви можете послідовно застосовувати FindByX(int)/ FindByY(int)шаблони скрізь, але Find(int X)/ Find(int Y)це неможливо, оскільки вони суперечать.

Переваги Find ()

• KISS. Findє простим і простим, і поряд з operator[]цим є одним із 2 найочікуваніших імен функцій у цьому контексті. (Деякі популярні варіанти того get, lookupчи fetch, в залежності від контексту).
• Як правило, якщо у вас є назва функції, це єдине відоме слово, яке точно описує, що функція виконує, використовуйте її. Навіть якщо є довше багатословне ім'я, яке трохи краще описує те, що робить функція. Приклад: Довжина проти NumberOfElements . Існує компроміс, і де провести межу, є предметом постійної дискусії.
• Як правило, добре уникати надмірностей. Якщо ми подивимось FindById(int id), ми можемо легко усунути надмірність, змінивши його на Find(int id), але є торгівля - ми втрачаємо деяку чіткість.

Ви також можете отримати переваги обох за допомогою сильно набраних ідентифікаторів:

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

Реалізація Id<>: Сильно вводити значення ідентифікаторів у C #

Коментарі тут, як і посилання вище, викликали численні занепокоєння щодо Id<Customer>того, про що я хотів би звернутися:

• Концерн 1: Це зловживання дженериками. CustomerIdі OrderIDрізні типи ( customerId1 = customerId2;=> хороший, customerId1 = orderId1;=> поганий), але їх реалізація майже однакова, тому ми можемо реалізувати їх або за допомогою копіювальної пасти, або за допомогою метапрограмування. Незважаючи на те, що в дискусії про викриття або приховування загального значення існує цінність, метапрограмування - це те, для чого потрібні дженерики.
• Концерн 2: Це не зупиняє прості mistakes./It's рішення в пошуках проблеми Основне питання , який видаляється за допомогою сильно типізованих Ідентифікатори неправильний порядок аргументів у виклику DoSomething(int customerId, int orderId, int productId). Сильно набрані ідентифікатори також запобігають іншим проблемам, включаючи ту, про яку було задано ОП.
• Занепокоєння 3: Це дійсно просто затьмарює код. Важко сказати, чи зберігається ідентифікатор int aVariable. Неважко сказати, що Id зберігається Id<Customer> aVariable, і ми навіть можемо сказати, що це ідентифікатор клієнта.
• Концерн 4: Ці ідентифікатори не є сильними типами, а лише обгортками. Stringце просто обгортка навколо byte[]. Обгортання або інкапсуляція не суперечить сильному набору тексту.
• Побоювання 5: Це сконструйовано. Ось мінімальна версія, хоча я рекомендую додавати operator==і operator!=, якщо ви не хочете покладатися виключно на 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; }
}

Інший спосіб думати про це - використовувати безпеку типу мови.

Ви можете реалізувати такий метод, як:

Find(FirstName name);

Якщо FirstName - це простий об'єкт, який обертає рядок, що містить ім'я та означає, що не може бути плутанини щодо того, що робить метод, ні в аргументах, з якими він викликається.

Я буду голосувати за явну декларацію, як FindByID .... Програмне забезпечення має бути створене для змін. Він повинен бути відкритим і закритим (SOLID). Тож клас відкритий для додавання подібного методу пошуку, наприклад, FindByName .. тощо.

Але FindByID закритий, і його реалізація перевірена.

Я не пропоную методів із предикатами, вони хороші на загальному рівні. Що робити, якщо на основі поля (ByID) у вас є повна інша методологія.

Я здивований, що ніхто не запропонував використовувати присудок, наприклад:

User Find(Predicate<User> predicate)

При такому підході ви не тільки зменшуєте поверхню свого API, але і надаєте більше контролю користувачеві, який його використовує.

Якщо цього недостатньо, ви завжди можете розширити його під свої потреби.