none
Interface As return type in C# RRS feed

Answers

  • By definition of what an interface is it is impossible to return an interface because interfaces cannot be allocated; there cannot be anything to return.

    Okay, that is the dramatic portion of what I am saying. You are asking about defining an interface as a return type.

    If an interface is defined to be the return type of a method then instances of classes derived from that interface can be returned. The benefit of doing that is no different from returning objects of classes derived from a class. Either way, we can specify the base class or interface as a return type and then return instances of classes derived from the base whether that base is a class or interface.



    Sam Hobbs
    SimpleSamples.Info


    Monday, March 12, 2018 2:43 AM
  • I'd say it adds some flexibility in specific cases. Lets say I have a collection of IShape's where IShape represents the interface shared by many "shapes". If I were to process some data and make run time decisions as to what method to call to convert the data into its derived implementation of IShape, if those methods returned the interface than I could save myself the boilerplate of changing type and adding it to the collection. So as I encounter data that should be sent a method which creates and returns a Rectangle : IShape I can simply return IShape, same with data representing Square : IShape. When you create a derived type and return it from within a method whose return type is the interface, you do not need to perform and casting or checking. That can be convenient when applicable.

    You can't say one is better than the other, you can only say in a given case it makes more sense to use one approach over the other...
    • Edited by Ritmo2k Monday, March 12, 2018 1:31 AM
    • Proposed as answer by CoolDadTxModerator Monday, March 12, 2018 4:48 PM
    • Marked as answer by Arash_89 Monday, March 12, 2018 9:38 PM
    Monday, March 12, 2018 1:29 AM
  • It depends on what you want to accomplish. If for instance the rule is that (using the code below) each class implements ICar which means it must have a read only property of Make.

    Yet this is only good if the rule to implement the Interface is done by the developer(s) on a project. You then have consistency along with on the road to a good object oriented pattern.

    In closing I suggest reading 

    Creating Variant Generic Interfaces 

    public interface ICar
    {
    	string Make {get;}
    }
    
    public class Miata : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Mazda";
    		}
    	}
    }
    
    public class Corvette : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Chevrolet";
    		}
    	}
    }
    
    public class Mustang : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Ford";
    		}
    	}
    }


     

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites



    Monday, March 12, 2018 1:37 AM
    Moderator
  • I think you're combining concepts that are better left separate, in terms of discussion. The usage of an interface as a return type is completely irrelevant. The question is really "when should you use an interface vs an (abstract) base class". They both do the same thing but are simply different approaches. I'd recommend that you google for the differences. In pure contract based programming you're going to be going with an interface but in the last couple of years there has been a switch away from interfaces to ABCs. 

    Interfaces are great when you're working with truly different types (i.e. validation, serializable, etc) but for related types an interface is harder to work with, requires more code to write, and is not as maintainable. Hence libraries and other code tend to use ABCs instead of interfaces. You have to decide which is best for your specific needs.

    Given the above, your question should really be "when should I use an interface/ABC as a return type instead of a specific type". The answer to that is whenever you don't know or want to hide the underlying type being returned. You don't know the actual type when you're defining members in an interface or ABC. Hence you'd use the interface/ABC as the return type.

    In other cases you simply want to hide the details. IEnumerable implementations are a great example of this. The implementations could return the MyEnumerableImplementation type they are actually using but it adds no value to the caller and may expose details that shouldn't be. Hence the use of an interface/ABC as the return type as well.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Arash_89 Monday, March 12, 2018 9:28 PM
    Monday, March 12, 2018 4:53 PM
    Moderator

All replies

  • I'd say it adds some flexibility in specific cases. Lets say I have a collection of IShape's where IShape represents the interface shared by many "shapes". If I were to process some data and make run time decisions as to what method to call to convert the data into its derived implementation of IShape, if those methods returned the interface than I could save myself the boilerplate of changing type and adding it to the collection. So as I encounter data that should be sent a method which creates and returns a Rectangle : IShape I can simply return IShape, same with data representing Square : IShape. When you create a derived type and return it from within a method whose return type is the interface, you do not need to perform and casting or checking. That can be convenient when applicable.

    You can't say one is better than the other, you can only say in a given case it makes more sense to use one approach over the other...
    • Edited by Ritmo2k Monday, March 12, 2018 1:31 AM
    • Proposed as answer by CoolDadTxModerator Monday, March 12, 2018 4:48 PM
    • Marked as answer by Arash_89 Monday, March 12, 2018 9:38 PM
    Monday, March 12, 2018 1:29 AM
  • It depends on what you want to accomplish. If for instance the rule is that (using the code below) each class implements ICar which means it must have a read only property of Make.

    Yet this is only good if the rule to implement the Interface is done by the developer(s) on a project. You then have consistency along with on the road to a good object oriented pattern.

    In closing I suggest reading 

    Creating Variant Generic Interfaces 

    public interface ICar
    {
    	string Make {get;}
    }
    
    public class Miata : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Mazda";
    		}
    	}
    }
    
    public class Corvette : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Chevrolet";
    		}
    	}
    }
    
    public class Mustang : ICar
    {
    	public string Make
    	{
    		get
    		{
    			return "Ford";
    		}
    	}
    }


     

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites



    Monday, March 12, 2018 1:37 AM
    Moderator
  • By definition of what an interface is it is impossible to return an interface because interfaces cannot be allocated; there cannot be anything to return.

    Okay, that is the dramatic portion of what I am saying. You are asking about defining an interface as a return type.

    If an interface is defined to be the return type of a method then instances of classes derived from that interface can be returned. The benefit of doing that is no different from returning objects of classes derived from a class. Either way, we can specify the base class or interface as a return type and then return instances of classes derived from the base whether that base is a class or interface.



    Sam Hobbs
    SimpleSamples.Info


    Monday, March 12, 2018 2:43 AM
  • I think you're combining concepts that are better left separate, in terms of discussion. The usage of an interface as a return type is completely irrelevant. The question is really "when should you use an interface vs an (abstract) base class". They both do the same thing but are simply different approaches. I'd recommend that you google for the differences. In pure contract based programming you're going to be going with an interface but in the last couple of years there has been a switch away from interfaces to ABCs. 

    Interfaces are great when you're working with truly different types (i.e. validation, serializable, etc) but for related types an interface is harder to work with, requires more code to write, and is not as maintainable. Hence libraries and other code tend to use ABCs instead of interfaces. You have to decide which is best for your specific needs.

    Given the above, your question should really be "when should I use an interface/ABC as a return type instead of a specific type". The answer to that is whenever you don't know or want to hide the underlying type being returned. You don't know the actual type when you're defining members in an interface or ABC. Hence you'd use the interface/ABC as the return type.

    In other cases you simply want to hide the details. IEnumerable implementations are a great example of this. The implementations could return the MyEnumerableImplementation type they are actually using but it adds no value to the caller and may expose details that shouldn't be. Hence the use of an interface/ABC as the return type as well.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Arash_89 Monday, March 12, 2018 9:28 PM
    Monday, March 12, 2018 4:53 PM
    Moderator
  • I wrote a reply but it got marked as spam. So I will try posting it in pieces.

    In pure contract based programming you're going to be going with an interface but in the last couple of years there has been a switch away from interfaces to ABCs.

    You should clarify what you are talking about but if an ABC is anything in the MSDN then it is irrelevant here. I posted a some links to some ABC in the MSDN and Microsoft documentation but the links are considered spam.

    Okay here is a sanitized version of the links. This omits the word that caused my post to be flagged as spam.

    ABCModel Enumeration [AX 2012]
    Something for Dynamics AX?
    Introduction to Building Windows Communication Foundation Service
    For understanding how a WCF service endpoint is composed.
    ABC Structure
    Contains the width of a character in a TrueType font.
    ABC Classification
    For inventory control.


    Sam Hobbs
    SimpleSamples.Info


    Tuesday, March 13, 2018 2:43 AM
  • The following is the remainder of what I said in the post marked as spam. If this gets posted then it means that it was the links to Microsoft that triggered the designation of spam.

    Given the above, your question should really be "when should I use an interface/ABC as a return type instead of a specific type".

    That is the same as asking "when should I use a base interface or class as a return type instead of a derived type". The answer is that if the method applies to all derived types then using the base class or interface requires one method. If that were done when the base is a class then the method should be in the base class but for interfaces we can't put an implementation in the interface. The question however is not asking whether interfaces are useful, the question implies that the use of an interface is decided and asks what are the advantages of doing that.



    Sam Hobbs
    SimpleSamples.Info

    Tuesday, March 13, 2018 2:48 AM
  • Anyone that is interested in knowing why my post was rejected as spam can look at My post got ate and was not spam.


    Sam Hobbs
    SimpleSamples.Info

    Tuesday, March 13, 2018 3:42 AM