Question

I have a set of classes with the same functions but with different logic. However, each class function can return a number of objects. It is safe to set the return type as the interface?

Each class (all using the same interface) is doing this with different business logic.

protected IMessage validateReturnType; <-- This is in an abstract class

public bool IsValid() <-- This is in an abstract class
{
    return (validateReturnType.GetType() == typeof(Success));
}

public IMessage Validate()
{
    if (name.Length < 5)
    {
        validateReturnType = new Error("Name must be 5 characters or greater.");
    }
    else
    {
        validateReturnType = new Success("Name is valid.");
    }

    return validateReturnType;
}

Are there any pitfalls with unit testing the return type of an function? Also, is it considered bad design to have functions needing to be run in order for them to succeed? In this example, Validate() would have to be run before IsValid() or else IsValid() would always return false.

Thank you.

Answer 1

However, each class function can
return a number of objects. It is safe
to set the return type as the
interface?

This is good practice and common. For example look at the way COM was built, it heavily relies on this methodology.

Are there any pitfalls with unit testing the return type of an function

No.

Also, is it considered bad design to have functions needing to be run in order for them to succeed? In this example, Validate() would have to be run before IsValid() or else IsValid() would always return false.

That’s fine for working with an object oriented programming paradigm, take for example working with sockets. It’s common to have a connect method before you can send and receive data.

That being said it’s good to keep less state than more state as a general rule because in that way it’s easier to prove your program is correct. For example you have to test each function that relies on this function not in one way but in 2 ways now. Possible program states grows exponentially if you have a lot of state. Take a look at functional programming if you are interested in why state is a bad thing.