Если вы всегда передаете минимум необходимых данных в функцию в подобных случаях

Допустим, у меня есть функция, IsAdminкоторая проверяет, является ли пользователь администратором. Давайте также скажем, что проверка администратора выполняется путем сопоставления идентификатора пользователя, имени и пароля с каким-то правилом (не важно).

В моей голове есть две возможные функции подписи для этого:

public bool IsAdmin(User user);
public bool IsAdmin(int id, string name, string password);

Я чаще всего иду на второй тип подписи, думая, что:

• Функция подписи дает читателю намного больше информации
• Логика, содержащаяся внутри функции, не должна знать о Userклассе
• Обычно это приводит к немного меньшему количеству кода внутри функции

Однако я иногда подвергаю сомнению этот подход, а также понимаю, что в какой-то момент он станет громоздким. Если, например, функция отобразит между десятью различными полями объекта в результирующее логическое значение, я, очевидно, отправлю весь объект целиком. Но кроме яркого примера, подобного этому, я не вижу причин для перехода к реальному объекту.

Я был бы признателен за любые аргументы в пользу любого стиля, а также за любые общие замечания, которые вы могли бы предложить.

Я программирую как в объектно-ориентированном, так и в функциональном стилях, поэтому вопрос следует рассматривать как относящийся ко всем идиомам.

Я лично предпочитаю первый метод просто IsAdmin(User user)

Его гораздо проще использовать, и если ваши критерии для IsAdmin изменятся позднее (возможно, на основе ролей или isActive), вам не нужно будет переписывать сигнатуру метода везде.

Это также, вероятно, более безопасно, поскольку вы не рекламируете, какие свойства определяют, является ли пользователь администратором или нет, или везде передаете свойство пароля. И Сирион делает хорошее замечание, что происходит, когда ваш idне соответствует name/ password?

Длина кода внутри функции не должна иметь большого значения, если метод выполняет свою работу, и я бы предпочел иметь более короткий и простой код приложения, чем код вспомогательного метода.

Первая сигнатура является превосходной, поскольку она позволяет инкапсулировать пользовательскую логику в сам Userобъект. Не имеет смысла иметь логику для построения кортежа «id, name, password» о вашей кодовой базе. Кроме того, это усложняет isAdminфункцию: что произойдет, если кто-то перейдет в, например, idчто не соответствует name? Что если вы хотите проверить, является ли данный пользователь администратором из контекста, в котором вы не должны знать его пароль?

Кроме того, как примечание к вашему третьему пункту в пользу стиля с дополнительными аргументами; это может привести к «меньшему количеству кода внутри функции», но куда девается эта логика? Это не может просто исчезнуть! Вместо этого он распространяется вокруг каждого места, где вызывается функция. Чтобы сохранить пять строк кода в одном месте, вы заплатили пять строк за использование функции!

Первый, но не (только) по причинам, приведенным другими.

public bool IsAdmin(User user);

Это тип безопасно. Тем более что User - это тип, который вы определили сами, у вас практически нет возможности транспонировать или переключать аргументы. Он явно работает с пользователями и не является какой-то универсальной функцией, принимающей любые int и две строки. Это большая часть смысла в использовании безопасного языка типа Java или C #, на который похож ваш код. Если вы спрашиваете об определенном языке, вы можете добавить тег для этого языка в свой вопрос.

public bool IsAdmin(int id, string name, string password);

Здесь подойдут любые int и две строки. Что мешает вам перенести имя и пароль? Второе - больше работы для использования и дает больше возможностей для ошибок.

Предположительно, обе функции требуют, чтобы user.getId (), user.getName () и user.getPassword () были вызваны либо внутри функции (в первом случае), либо перед вызовом функции (во втором), поэтому количество сцепления одинаково в любом случае. На самом деле, поскольку эта функция действительна только для пользователей, в Java я исключил бы все аргументы и сделал бы этот метод экземпляра для объектов пользователя:

user.isAdmin();

Поскольку эта функция уже тесно связана с пользователями, имеет смысл сделать ее частью того, чем является пользователь.

PS Я уверен, что это всего лишь пример, но похоже, что вы храните пароль. Вместо этого вы должны хранить только криптографически безопасный хеш пароля. Во время входа в систему указанный пароль должен быть хеширован аналогичным образом и сопоставлен с сохраненным хешем. Следует избегать отправки паролей в виде простого текста. Если вы нарушаете это правило и isAdmin (int Str Str) регистрирует имя пользователя, то если вы транспонировали имя и пароль в своем коде, вместо этого можно будет зарегистрировать пароль, что создает проблему безопасности (не записывайте пароли в журналы ) и является еще одним аргументом в пользу передачи объекта вместо его составных частей (или использования метода класса).

Если ваш язык выбора не передает структуры по значению, тогда (User user)вариант кажется лучше. Что если однажды вы решите отказаться от имени пользователя и просто использовать идентификатор / пароль для идентификации пользователя?

Кроме того, такой подход неизбежно приводит к длинным и чрезмерным вызовам методов или несоответствиям. Передача 3 аргументов в порядке? Как насчет 5? Или 6? Зачем думать об этом, если передача объекта обходится дешево с точки зрения ресурсов (возможно, даже дешевле, чем передача 3 аргументов)?

И я (вроде) не согласен с тем, что второй подход дает читателю больше информации - интуитивно, вызов метода спрашивает «есть ли у пользователя права администратора», а не «имеет ли данная комбинация идентификатор / имя / пароль права администратора».

Таким образом, если передача Userобъекта не приведет к копированию большой структуры, первый подход будет более понятным и логичным для меня.

Я бы, наверное, и то и другое. Первый как внешний API, с некоторой надеждой на стабильность во времени. Вторая - частная реализация, вызываемая внешним API.

Если через какое-то время мне придется изменить правило проверки, я просто напишу новую приватную функцию с новой сигнатурой, вызываемой внешней.

Это имеет преимущество в простоте изменения внутренней реализации. Также действительно обычно, что в какой-то момент вам могут понадобиться обе функции, доступные одновременно, и вызывать одну или другую в зависимости от изменения внешнего контекста (например, у вас могут быть сосуществующие старые пользователи и новые пользователи с разными полями).

Что касается названия вопроса, то в обоих случаях вы предоставляете минимально необходимую информацию. Пользователь, кажется, самая маленькая структура данных, связанных с приложением, содержащая информацию. Три поля id, password и name кажутся наименьшими необходимыми данными реализации, но на самом деле они не являются объектами уровня приложения.

Другими словами, если вы имеете дело с базой данных, пользователь будет записью, а id, пароль и логин будут полями в этой записи.

Есть один негативный момент для отправки классов (ссылочных типов) в методы, а именно, Уязвимость массового назначения . Представьте, что вместо IsAdmin(User user)метода у меня есть UpdateUser(User user)метод.

Если Userкласс имеет вызываемое логическое свойство IsAdmin, и если я не проверяю его во время выполнения моего метода, то я уязвим для массового назначения. GitHub был атакован этой самой подписью в 2012 году.

Я бы пошел с этим подходом:

public bool IsAdmin(this IUser user) { /* ... */ }

public class User: IUser { /* ... */ }

public interface IUser
{
    string Username {get;}
    string Password {get;}
    IID Id {get;}
}

• Использование типа интерфейса в качестве параметра для этой функции позволяет передавать объекты User, определять фиктивные объекты User для тестирования и дает вам больше гибкости в отношении как использования, так и обслуживания этой функции.

• Я также добавил ключевое слово, thisчтобы сделать функцию методом расширения всех классов IUser; таким образом, вы можете написать код более удобным для OO способом и использовать эту функцию в запросах Linq. Проще было бы определить эту функцию в IUser и User, но я предполагаю, что есть какая-то причина, по которой вы решили поместить этот метод вне этого класса?

• Я использую пользовательский интерфейс IIDвместо того int, чтобы переопределять свойства вашего идентификатора; например , если вам когда - нибудь понадобится , чтобы перейти от intк long, Guidили что - то другое. Это, вероятно, излишне, но всегда хорошо пытаться сделать вещи гибкими, чтобы вы не были привязаны к ранним решениям.

• NB. Ваш объект IUser может находиться в другом пространстве имен и / или сборке, чем класс User, поэтому у вас есть возможность полностью отделить свой код пользователя от кода IsAdmin, при этом они могут использовать только одну библиотеку, на которую ссылаются. Именно то, что вы делаете, вызывает то, как вы подозреваете, что эти предметы будут использоваться.

Отказ от ответственности:

В своем ответе я сосредоточусь на проблеме стиля и забуду о том, что ID, логин и простой пароль - хороший набор параметров для использования с точки зрения безопасности. Вы должны быть в состоянии экстраполировать мой ответ на любой базовый набор данных, который вы используете, чтобы выяснить о привилегиях пользователя ...

Я также считаю user.isAdmin()эквивалентным IsAdmin(User user). Это выбор для вас.

Ответить:

Я рекомендую только одному из пользователей:

public bool IsAdmin(User user);

Или используйте оба варианта:

public bool IsAdmin(User user); // calls the private method below
private bool IsAdmin(int id, string name, string password);

Причины публичного метода:

При написании общедоступных методов обычно полезно подумать о том, как они будут использоваться.

В этом конкретном случае причиной, по которой вы обычно вызываете этот метод, является выяснение, является ли определенный пользователь администратором. Это метод, который вам нужен. Вы действительно не хотите, чтобы каждый вызывающий абонент выбирал правильные параметры для отправки (и рисковал ошибками из-за дублирования кода).

Причины частного метода:

Частный метод, получающий только минимальный набор обязательных параметров, иногда может быть полезен. Иногда не так много.

Одно из преимуществ разделения этих методов состоит в том, что вы можете вызывать закрытую версию из нескольких открытых методов в одном классе. Например, если вы хотите (по какой-либо причине) иметь немного другую логику для Localuserи RemoteUser(может быть, есть настройка для включения / выключения удаленных администраторов?):

public bool IsAdmin(Localuser user); // Just call private method
public bool IsAdmin(RemoteUser user); // Check if setting is on, then call private method
private bool IsAdmin(int id, string name, string password);

Кроме того, если по какой-либо причине вам нужно сделать закрытый метод общедоступным ... вы можете. Это так же просто, как просто перейти privateна public. Это может показаться не таким уж большим преимуществом для этого случая, но иногда это действительно так.

Кроме того, при модульном тестировании вы сможете выполнять гораздо больше атомных тестов. Обычно очень приятно не создавать полноценный пользовательский объект для запуска тестов по этому методу. И если вы хотите полное покрытие, вы можете проверить оба звонка.

public bool IsAdmin(int id, string name, string password);

это плохо по причинам, перечисленным. Это не значит

public bool IsAdmin(User user);

автоматически хорошо. В частности , если пользователь является объектом , имеющим такие методы , как: getOrders(), getFriends(), getAdresses(), ...

Вы можете рассмотреть возможность рефакторинга домена с типом UserCredentials, содержащим только идентификатор, имя, пароль и передачу его в IsAdmin вместо всех ненужных данных пользователя.