title: Using multiple interfaces in Golang
body: <p>I'm learning Golang and as an exercise in using interfaces I'm building a toy program. I'm having some problem trying to use a type that &quot;should implement&quot; two interfaces - one way to solve that in C++ and Java would be to use inheritance(there are other techniques, but I think that is the most common). As I lack that mechanism in Golang, I'm not sure how to proceed about it. Below is the code:</p>
  <pre><code>var (
      faces = []string{&quot;Ace&quot;, &quot;Two&quot;, &quot;Three&quot;, &quot;Four&quot;, &quot;Five&quot;, &quot;Six&quot;, &quot;Seven&quot;, &quot;Eight&quot;, &quot;Nine&quot;, &quot;Ten&quot;, &quot;Jack&quot;, &quot;Queen&quot;, &quot;King&quot;}
  
      suits = []string{&quot;Hearts&quot;, &quot;Diamonds&quot;, &quot;Spades&quot;, &quot;Clubs&quot;}
  )
  
  type Card interface {
      GetFace() string
      GetSuit() string
  }
  
  type card struct {
      cardNum int
      face    string
      suit    string
  }
  
  func NewCard(num int) Card {
      newCard := card{
          cardNum: num,
          face:    faces[num%len(faces)],
          suit:    suits[num/len(faces)],
      }
  
      return &amp;newCard
  }
  
  func (c *card) GetFace() string {
      return c.face
  }
  
  func (c *card) GetSuit() string {
      return c.suit
  }
  
  func (c *card) String() string {
      return fmt.Sprintf(&quot;%s%s &quot;, c.GetFace(), c.GetSuit())
  }
  </code></pre>
  <p>What I'm trying to achieve:</p>
  <ul>
  <li>I would like to hide my struct type and only export the interface so that the clients of the code use only the <em>&quot;Card&quot;</em> interface</li>
  <li>I would like to have a string representation of the struct, hence the implementation of the interface with the <em>&quot;String()&quot;</em> method in order to be able to call <em>&quot;fmt.Println()&quot;</em> on instantiations of my struct</li>
  </ul>
  <p>The problem comes when I'm trying to use a new card though the &quot;Card&quot; interface and also trying to get the string representation. I cannot pass the interface as the parameter of the implementation of the <em>&quot;String()&quot;</em> method as there is a compiler error which is related to the addressability of an interface at the core language level(still digging through that documentation). The very simple example of testing exposes the issue:</p>
  <pre><code>func TestString(t *testing.T) {
      card := NewCard(0)
      assert.EqualValues(t, &quot;AceHearts &quot;, card.String(), &quot; newly created card's string repr should be 'AceHearts '&quot;)
  }
  </code></pre>
  <p>The compiler tells me, for good reason, that <em>&quot;card.String undefined (type card has no field or method string)&quot;</em>. I could just add the <em>&quot;String()&quot;</em> method to my <em>&quot;Card&quot;</em> interface, but I do not find that to be clean: I have other entities implemented with the same model and I would have to add that redundancy everywhere; there is already an interface with that method.</p>
  <p>What would be a good solution for the above issue that I'm having?</p>
  <p><strong>Edit:</strong>(to address some of the very good comments)</p>
  <ul>
  <li>I do not expect to have another implementation of the <em>Card</em> interface; I'm not sure I grasp why would I want to do that, that is change the interface</li>
  <li>I would like to have the <em>Card</em> interface to hide away implementation details and for the clients to program against the interface and not against the concrete type</li>
  <li>I would like to always have access to the String() interface for all clients of the &quot;card struct&quot; instantiations(including the ones instantiated via the Card interface). I'm not interested in having clients only with the String interface. In some other languages this can be achieved by implementing both interfaces - multiple inheritance. I'm not saying that is good or wrong, or trying to start a debate about that, I'm just stating a fact!</li>
  <li>My intent is to find out if the language has any mechanism to fulfill those requirements simultaneously. If that is not possible or maybe from the point of view of the design the problem should be tackled in a different manner, then I'm ready to be educated</li>
  <li>Type assertions are very verbose and explicit and would expose implementation details - they have their places but I do not think they are appropriate in the situation I have</li>
  </ul>