Geek Answers Handbook

Should the interface method return a user object?

In the discussion I had, the question arose whether the interface method should return a user object against a primitive type.

eg.

public interface IFoo { bool SomeMethod(); }

vs

 public interface IFoo { MyFooObj SomeMethod(); }

Where is MyFooObj:

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

The argument is that you can easily add properties to an object in the future without changing the interface contract.

I'm not sure what the standard guidelines for this are?

+8
standards c #
source share
9 answers

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

+10
source share

My standard answer is YAGNI .

You can always make a difference if this happens, in particular if you control the full source of the application and how the interface is used.

Logical flow around only to predict the future is only the addition of complications and additional levels of abstraction when they are not currently needed.

If you use DDD and certain modeling methods in your code base, it makes sense to have such aliases for logical operations, if they make sense in your domain (but I do not see this to be the case for one logical value).

+7
source share

I do not see the point of encapsulation of primitive types in the user object.

If you change the definition of this custom object, you will actually change the contract because the function does not return the same.

I think this is a redesigned "template" again.

+3
source share

There are no general recommendations.

As you pointed out, if you have semantics around the return type that you think are certain that they might change or may need to be updated in the future, it might be better to return a complex type.

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

+3
source share

It depends on what you like. My opinion is that in your example for example, I stuck with a simple bool definition in an interface definition for these reasons:

  • This is the easiest reading opportunity.
  • no one is looking for methods that are not available

IMHO, an object makes sense only when the result requires a certain complexity / grouping.

+2
source share

If it does not need to start with the fact that you should not wrap it, changing what returns inside the object is just the same as changing the interface, which interrupts rule number one programming with interfaces.

Its right there with the design for expansion, YAGNI (you won’t need it).

As a side note, I was told about such things at the beginning of my career.

+2
source share

If you ever need to return something more than logical, it is very likely that you are going to change other parts of the interface. Do not make things more complicated than they should be: simplicity is a prerequisite for reliability.

+2
source share

Just thought that I would say that if MyFooObj is in an assembly that is strong named, you update it, its version is updated - old clients are interrupted immediately (for example, InvalidCastException) due to version mismatch (it will not try partial binding due to strong immunity) if they are not recompiled with the new version. You have still changed the contract for the interface. So it’s best to keep things simple, return a primitive type, and more clearly declare your contract change.

+1
source share

In addition to the other answers, adding a new field to a user class is technically still a potential violation of changes for users of the interface. Link

+1
source share

More articles:


All Articles