Is accepting Object as a parameter acceptable?

Question

Let us say I have a textbox or any other form of input that asks for a social security number. I do want to note that the SSN is a pure example I simply thought of as of right now. This input will naturally be stored as a string initially.

string s = Console.ReadLine();

Let us say I want to have a method that validates an SSN and it might be used throughout my code in all sorts of places. Heck, I might even call the method on a variable which has not been determined by user-input.

Is this acceptable?

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

Or would you guy insist that I ask for a specific datatype, e.g

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

and therefor I am required to convert the input to the correct datatype BEFORE I call the method on it.

BTW: I am not asking how to do a proper IsValidSSN code :) I just wanted to give an example of what I meant when I said: Can I accept the Object datatype as a parameter or should I try to avoid it?

Answer 1

If you must accept an object I would at least have overloads of the method which take strongly typed parameters. Then have the object variants feed into these methods.

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

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

Answer 2

It COMPLETELY depends on your design and where you want your validation to occur. It really fundamentally depends upon your overall architecture and your class hierarchy. It's not wrong to do it either way; just be sure that it's the way that fits with your architectural design.

Answer 3

In your above example it is far easier to create a typed IsValidSSN. Generally I find that typing reduces bugs and flexibility.

Under circumstances in which flexibility if paramount then using Object is probably the best choice, but expect to face a few cast clash exceptions in the logs.

For all other cases be strict with your typing, or write it in python.

Answer 4

Personally, I would make an SSN class and be able to ask that SSN if it was valid or not. It's important to have classes that represent principals in your business logic. This is very much, for example, what you might do with something that requires more validation like a credit card class. Handing around objects is not the best if you can avoid it and handing around something that is a principal in your business logic as a primitive is bad too (your architecture makes SSN1 + SSN2 = SSN3 perfectly valid, even though in business logic, it's nonsense).

Answer 5

I see no value in accepting an Object in this case. Think through how you expect that function to work. (Clearly you haven't, since the code you posted doesn't work). I think you're planning something like this:

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

How is that better than:

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

The overloaded methods are simpler, and faster, since they more the decision on what to do from runtime to compile time.

Answer 6

In this instance, I would say it was unacceptable. What if the input has dashes, or some other separating character (eg: ###-##-####)? You obviously wouldn't be able to parse the value as an integer, but the value would still be valid. How about using a regular expression instead to ensure the value is what you've desired.

In terms of using the type "Object" as a parameter, this is completely valid in many instances. In fact, it is used throughout the .NET Framework (look at event delegates):

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

This would be a simple case of Boxing/Unboxing, which was really the only way of performing "Generic" operations on variables until .NET 2.0.

You can also use Generics to solve this problem without the need for casting. If you create an interface that implements something like INumeric (I don't know if that is the actual interface) or IComparable you should be able to perform the operation in a more elegant fashion:

public bool IsValidSNN(INumeric SSN){}