Принимает объект как параметр приемлемый?

Question

Скажем, у меня есть текстовое поле или любая другая форма ввода, которая запрашивает номер социального страхования. Я хочу отметить, что SSN - это чистый пример, о котором я просто думал сейчас. Этот ввод, естественно, будет сохранен в виде строки изначально.

string s = Console.ReadLine(); 

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

Это приемлемо?

public bool IsValidSSN(Object SSN) 
{ 
int mySSN; 
    if(Int.Parse(SSN == false) 
    { 
    mySSN = Convert.toInt32(SSN); 
    } 
... 
} 

Или вы парень настаивают, что я прошу для определенного типа данных, например

public bool IsValidSSN(int SSN) 
{ 
... 
} 

и для этого я должен преобразовать входные данные в правильный тип данных ПЕРЕД я вызываю метод на него ,

BTW: Я не спрашиваю, как сделать правильный код IsValidSSN :) Я просто хотел привести пример того, что имел в виду, когда я сказал: могу ли я принять тип данных Object в качестве параметра или попытаться его избежать ?

Answer 1

Если вы должны принять объект, я бы по крайней мере имел перегрузки метода, который принимает строго типизированные параметры. Затем используйте варианты объектов в этих методах.

public bool IsValidSSN(object ssn) { 
    ... 
    IsValidSSN(Convert.ToInt32(ssn)); 
    ... 
} 

public bool IsValidSSN(int ssn) { 
    ... 
} 

Answer 2

Это ПОЛНОСТЬЮ зависит от вашего дизайна и того, где вы хотите, чтобы ваша проверка произошла. Это в корне зависит от вашей общей архитектуры и иерархии классов. Нехорошо делать это в любом случае; просто убедитесь, что это способ, который соответствует вашему архитектурному дизайну.

Answer 3

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

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

Для всех остальных случаев будьте строгими с вашей типизацией или напишите в python.

Answer 4

Лично я сделал бы класс SSN и смог бы спросить, что SSN, если оно действительно, или нет. Важно иметь классы, которые представляют принципы в вашей бизнес-логике. Это очень, например, то, что вы можете сделать с чем-то, что требует большей проверки, как класс кредитной карты. Обход объектов не самый лучший, если вы можете избежать этого и передать что-то, что является основным в вашей бизнес-логике, так как примитив тоже плохой (ваша архитектура делает SSN1 + SSN2 = SSN3 совершенно правильной, хотя в бизнес-логике это абсурд).

Answer 5

Я не вижу значения при принятии объекта в этом случае. Подумайте, как вы ожидаете, что эта функция будет работать. (Очевидно, что вы этого не сделали, поскольку код, который вы опубликовали, не работает).Я думаю, что вы что-то подобное планирование:

if (SSN is string) 
    SSN = Convert.toInt32(SSN); 
else if (SSN is TextBox) 
    SSN = Convert.toInt32(SSN.Value); 
else /* etc */ 

Как это лучше, чем:

bool isValidSSN(int SSN) { /* real valuation code */ } 
bool IsValidSSN(String SSN) { return isValidSSN(Convert.toInt32(SSN)); } 
bool IsValidSSN(TextBox SSN) { return isValidSSN(Convert.toInt32(SSN.Value)); } 

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

Answer 6

В этом случае я бы сказал, что это неприемлемо. Что делать, если на входе есть тире или какой-либо другой разделительный символ (например: ### - ## - ####)? Вы, очевидно, не сможете проанализировать значение как целое число, но значение все равно будет действительным. Как насчет использования регулярного выражения вместо этого, чтобы гарантировать, что это то, что вы хотели.

Что касается использования типа «Объект» в качестве параметра, это вполне допустимо во многих случаях. На самом деле, он используется во всей .NET Framework (смотрите на делегатов мероприятия):

public void Control_MouseOver(object sender, MouseEventArgs e){} 

Это будет простой случай бокса/распаковка, который был действительно единственный способ выполнения «Generic» операции по переменным до .NET 2.0.

Вы также можете использовать Generics для решения этой проблемы без необходимости литья. Если вы создаете интерфейс, который реализует что-то вроде INumeric (я не знаю, является ли это фактическим интерфейсом) или IComparable, вы должны иметь возможность выполнить операцию более элегантным образом:

public bool IsValidSNN (INumeric SSN) {}