Приемлем ли объект в качестве параметра приемлемым? - PullRequest
Новая
       24

Приемлем ли объект в качестве параметра приемлемым?

2 голосов
/ 09 июня 2009

Допустим, у меня есть текстовое поле или любая другая форма ввода, которая запрашивает номер социального страхования. Я хочу отметить, что 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)
{
...
}

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

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

Ответы [ 6 ]

7 голосов
/ 09 июня 2009

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

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

public bool IsValidSSN(int ssn) {
  ...
}
2 голосов
/ 09 июня 2009

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

1 голос
/ 09 июня 2009

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

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)); }

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

0 голосов
/ 09 июня 2009

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

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

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

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

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

public bool IsValidSNN (INumeric SSN) {}

0 голосов
/ 09 июня 2009

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

0 голосов
/ 09 июня 2009

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

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

Во всех остальных случаях будьте строги в написании текста или напишите на питоне.

...