Should an interface method return a custom object? [closed]

Question

A question was raised in a discussion I had around whether an interface method should return a Custom object vs a primitive type.

e.g.

public interface IFoo
{
      bool SomeMethod();
}

vs

public interface IFoo
{
    MyFooObj SomeMethod();
}

Where MyFooObj is:

public class MyFooObj
{
     bool SomeProp{get;set;}
}

The argument being that you can easily add properties to the object in the future without needing to change the interface contract.

I am unsure what the standard guidelines on this are?

Answer 1

IMHO Changing the MyFooObj is the same as changing/adding methods to the IFoo Interface - so no I don't think it's a good idea add just another abstraction - remember YAGNI

Answer 2

My standard response is - YAGNI.

You can always change things if it turns out that way, in particular if you control the full source of the application and how the interface is used.

Wrapping a boolean just in order to forecast the future is only adding complication and additional layers of abstraction when they are not currently needed.

If you are using DDD and specific modelling techniques in your codebase, is can make sense to have such aliases to booleans, if they are meaningful in your domain (but I can't see this being the case for a single boolean value).

Answer 3

I don't see the point of encapsulating primitive types in a custom object.

If you change the definition of this custom object, then you actually change the contract because the function doesn't return the same thing.

I think it's again an over-engineered "pattern".

Answer 4

There are no general guidelines regarding this.

As you pointed out, if you have semantics around the return type that you think strongly believe may change or may need to be updated in the future it may be better to return the complex type.

But the reality is that in most circumstances it is better to keep things simple and return the primitive type.