CODEWITHSUNDEEP
oopgo
Poh Zi How
Poh Zi How

Reputation: 1569

Golang OOP clarification

I have two interfaces written in go, one which is a subset of the other

type x interface {
    a()
}

type y interface {
    a()
    b()
}

I also have a struct that has methods as such

type z struct {
    some string
}

func (s z) a() {
    // do stuff
}

func (s z) b() {
    // do stuff
}

I have a few questions regarding this, namely:

  1. Am I right to say that z implements both x and y?
  2. What is the OOP concept for one struct implementing multiple interfaces in this way?

I tried asking a few colleagues, who seem to lean towards polymorphism as the answer although they are not too sure. The wikipedia entry for polymorphism says that it "is the provision of a single interface to entities of different types", but this feels like the direct reverse to me. I have also found in other sources (eg. this) that Go is "not really a OOP language".

Upvotes: 2

Views: 877

Answers (4)

shanwije
shanwije

Reputation: 610

There is no concept of inheritance in Go. And it promotes composition over the inheritance.

From the Go FAQ:

There is no type hierarchy: types just are, they don't have to announce their relationships. These simplifications allow Go to be expressive yet comprehensible without sacrificing, well, sophistication.

https://golang.org/doc/faq#principles

Upvotes: 0

Joshua Kolden
Joshua Kolden

Reputation: 425

You are correct to say that z implements both interfaces.

Interfaces are in themselves a general programming concept not spacific to object oriented languages. some object oriented languages like Java and Go provide a way to define and implement interfaces, while others do not.

It is in fact a type of polymorphism because you are saying that a specific set of functions, or methods, may be implemented by different data structure types. Just as the wikipedia article suggests. It can also be thought of as type abstraction.

Go is capable of supporting object oriented, and procedurally oriented programming styles. It is considered an object oriented programming language.

Go is a strongly typed language and interfaces allow Go programmers to define types by their methods, in addition to the other way of defining types by data structure.

Upvotes: 0

Ayman
Ayman

Reputation: 11585

I've had a hard time getting the hang of Go interfaces at first. I'm coming from many years experience in Java, C++, Python... The best way IMHO to get the most out of Go, and any other new language is not to write Java or C++ in Go syntax. Understand how things work in Go and use it. Terminology may not be exact 1-to-1 mapping, and that does not matter.

Think of a Go interface as a group of method signatures operating on some group of data (struct). Similar to how Java interface is just a set of method signatures on a class. The main difference is that in Go, you do not need to specify that the struct implements an interface, the language will do that for you. If you specify the methods on a struct, it automatically implements the interface.

Upvotes: 2

svsd
svsd

Reputation: 1869

Yes, z implements both x and y. You can prove that by using a variable declaration to assign a concrete type to an interface type:

var _ x = z{}
var _ y = z{}

That gives you a compile time check to ensure that a type implements the interfaces you want it to.

As a side note, if you explicitly wanted y to be x + some more methods, then it'd make sense to write it like this:

interface y {
    x
    b()
}

About the naming, if a type implements two different interfaces which share some methods, I'd call it just that - a type that's implementing two different interfaces. One interface being a subset of another doesn't matter.

Moreover in Go, types (non struct types as well) are not associated with interfaces when they are defined. Even if a type was not written to implement some interface, you can make it implement any number of interfaces by defining new interfaces with different names and/or different combinations of methods from the type. That makes giving a name to the concept even harder - how would you know the name at the time of type definition when interfaces may be defined later in another package?

Upvotes: 7

Related Questions