It's simple example what I want:
I have object of B and use function step1 from struct A (common functionality). I need to redefine function step2 for B which runs inside A.
package main
import "fmt"
type A struct {}
func (a *A) step1() {
a.step2();
}
func (a *A) step2 () {
fmt.Println("get A");
}
type B struct {
A
}
func (b *B) step2 () {
fmt.Println("get B");
}
func main() {
obj := B{}
obj.step1()
}
How can I do it?
// maybe
func step1(a *A) {
self.step2(a);
}
Go doesn't do polymorphism. You have to recast what you want to do in terms of interfaces, and functions (not methods) that take those interfaces.
So think what interface does each object need to satisfy, then what functions you need to work on that interface. There are lots of great examples in the go standard library, eg io.Reader, io.Writer and the functions which work on those, eg io.Copy.
Here is my attempt to recast your example into that style. It doesn't make a lot of sense, but hopefully it will give you something to work on.
package main
import "fmt"
type A struct {
}
type steps interface {
step1()
step2()
}
func (a *A) step1() {
fmt.Println("step1 A")
}
func (a *A) step2() {
fmt.Println("get A")
}
type B struct {
A
}
func (b *B) step2() {
fmt.Println("get B")
}
func step1(f steps) {
f.step1()
f.step2()
}
func main() {
obj := B{}
step1(&obj)
}
Related
I'd like to provide multiple implementations for the following interface:
type API interface {
A()
B()
C()
}
According to my use cases, all implementations should share the exact same logic for function A and B while function C will have different logic for different implementations.
So I've created the following common implementation to be embedded:
type Common struct {}
func (c *Common) A() {}
func (c *Common) B() {}
To create two implementations for the interface above, I can just do the following:
type FirstImpl struct { Common }
func (i *FirstImpl) C() {}
type SecondImpl struct { Common }
func (i *SecondImpl) C() {}
Everything works just fine until I find out that function C needs to be called inside function B. Note that the logic for function B should still be the same across two implementations despite that we may get different results calling C inside B.
I'm wondering if this is a common pattern in Go and if there is an elegant way to handle it.
You want to emulate late binding.
One way to achieve this is by using a function pointer, and constructors for implementations:
type CommonImpl struct {
cimpl func()
}
func (c CommonImpl) C() { c.cimpl() }
type FirstImpl struct {
CommonImpl
}
func NewFirstImpl() APIImpl {
ret:=FirstImpl{}
ret.cimpl=ret.c
return &ret
}
With this implementation, you can call the derived-type C().
An alternative would be to pass the function as an argument:
func (c CommonImpl) C(bfunc func()) {
}
...
x:=FirstImpl{}
x.C(x.B)
Or with an interface:
type BIntf interface {
B()
}
func (c CommonImpl) C(b BIntf) {
}
x:=FirstImpl{}
x.C(x)
In Go, how can I mock an interface without having to implement every method? Let's say I have a Car interface and a Corolla struct that implements that interface:
type Car interface {
changeTire()
startEngine()
....
refuel()
}
type Corolla struct {
...
}
func (c Corolla) changeTire() {...}
func (c Corolla) startEngine() {...}
func (c Corolla) refuel() {...}
Let's say I also have a Garage struct that depends on Car:
type Garage struct {
MyCar Car
}
func (g Garage) PrepareCarToDrive() {
g.MyCar.changeTire()
g.MyCar.refuel()
g.MyCar.startEngine()
}
And I want to test Garage, so I create a MockCar that implements Car
type MockCar struct {
...
}
func (c MockCar) changeTire() {...}
func (c MockCar) startEngine() {...}
func (c MockCar) refuel() {...}
Now I have tests that test PrepareCarToDrive and I use the MockCar:
func TestGarage_PrepareCarToDrive_DoesSomething(t *testing.T) {
mockCar := MockCar{}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do X
...
}
func TestGarage_PrepareCarToDrive_DoesSomethingElse(t *testing.T) {
mockCar := MockCar{}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do Y
...
}
My question is, how can I have mockCar do different things each test? I know that I can create a different mock implementation of Car for each test. But this will get out of hand really quickly as I add more methods to Car.
I'm coming from a Java background so I'm looking for something like Mockito that will let me mock just the methods I need for each test.
What is the best way to do this in Go? Or am I missing something more fundamental?
If you embed the interface type itself in your mock struct, you can then only implement the methods you need. For example:
type MockCar struct {
Car
...
}
func (c MockCar) changeTire() {...}
Even though your struct only implements changeTire explicitly, it still satisfies the interface because the Car field provides the rest. This works as long as you don't try to call any of the unimplemented methods (which will cause a panic because Car is nil)
The easiest method is to use some base implementation as an embed for your test structure, and only override the method you're testing. Example using your types:
type MockCar struct {
Corolla // embedded, so the method implementations of Corolla get promoted
}
// overrides the Corolla implementation
func (c MockCar) changeTire() {
// test stuff
}
// refuel() and startEngine(), since they are not overridden, use Corolla's implementation
https://play.golang.org/p/q3_L1jf4hk
An alternative, if you need a different implementation per test, is to use a mock with function fields:
type MockCar struct {
changeTireFunc func()
startEngineFunc func()
....
refuelFunc func()
}
func (c MockCar) changeTire() {
if c.changeTireFunc != nil {
c.changeTireFunc()
}
}
func (c MockCar) startEngine() {
if c.startEngineFunc != nil {
c.startEngineFunc()
}
}
func (c MockCar) refuel() {
if c.refuelFunc != nil {
c.refuelFunc()
}
}
// test code
func TestGarage_PrepareCarToDrive_DoesSomething(t *testing.T) {
// let's say we require refuel(), but the default implementation is fine
// changeTire(), however, requires a mocked testing implementation
// and we don't need startEngine() at all
mockCar := MockCar{
changeTireFunc: func() {
// test functionality
},
refuelFunc: Corolla.refuel,
}
garageUnderTest := Garage{}
garageUnderTest.MyCar = mockCar
// some other setup
// when Garage calls mockCar.changeTire(), should do X
...
}
https://play.golang.org/p/lf7ny-lUCS
This style is a bit less useful when you're trying to use another type's methods as the default implementation, but can be very useful if you have some stand-alone functions that can be used as your default or test implementation, or if a trivial return is acceptable for functions you haven't specifically mocked (like the behavior of the mocked startEngine() in the example above, which does nothing at all when called because the startEngineFunc field is nil).
You can also, if you wish, bake the default implementation (like a call to (Corolla{}).startEngine()) into the mock method if the relevant function field is nil. This allows you the best of both worlds, with a default non-trivial implementation and the ability to hotswap out implementations at will on the mock just by changing the relevant function field.
I am learning go lang and i was wondering if there is a way to do something like this:
type Foo struct {
...
}
type Bar struct {
Foo
...
}
func getFoo() Foo {
return Bar{...}
}
In an object oriented language, such code should work without problems, but in go it throws me an error, saying that getFoo() must return an instance of class Foo.
Is there a way to do polymorphism similar to what i've described in Go?
Go is not a typical OO language. Also each language has it own way of doing things. You can use interface and composition to achieve what you desire to, as shown below:
package main
import "fmt"
type Foo interface {
printFoo()
}
type FooImpl struct {
}
type Bar struct {
FooImpl
}
type Bar2 struct {
FooImpl
}
func (f FooImpl)printFoo(){
fmt.Println("Print Foo Impl")
}
func getFoo() Foo {
return Bar{}
}
func main() {
fmt.Println("Hello, playground")
b := getFoo()
b.printFoo()
}
http://play.golang.org/p/iR8QkD3DnP
In Go, polymorphism is achieved by implementing interfaces.
type Being interface {
somemethod()
}
type Foo struct {}
type Bar struct {
Foo
}
type Baz struct {
Foo
}
// `Bar` and `Baz` implement `Being`
func (b *Bar) somemethod() {}
func (b *Baz) somemethod() {}
func getAnyFoo(b *Being) Foo {
return b.Foo
}
Therefore, anything implements an empty interface.
type Foo struct {}
type Bar struct {
Foo
}
// Get anything and extract its `Foo` if anything is a Bar
func getAnyFoo(i interface{}) Foo {
// Normally this would need a type switch to check the type
mybar := i.(Bar)
return mybar.Foo
}
If you know the types to use you could put them to an array list to implement a kind of polymorph instancing:
package main
import (
"fmt"
"encoding/json"
)
type Hans struct{
Miau string
}
type Keule struct {
Wuff string
}
func (K Keule)ppp() {
fmt.Printf(K.Wuff)
}
func (K Hans)ppp() {
fmt.Printf(K.Miau)
}
func (K Keule)TypeInfo() int {
return 0
}
func (K Hans)TypeInfo() int {
return 1
}
type Mega interface {
ppp()
TypeInfo() int
}
var j_a = `{
"Kein_Alter": "nix",
"Miau": "lala",
"class": 0
}`
var j_b = `{
"Alter": "nix",
"Wuff": "lolo",
"Class": 1
}`
type Class struct {
Class int
}
func (K *Class)ppp() {
fmt.Printf("%d", K.Class)
}
func Unmarshal_K(b []byte) (Mega, error) {
var k Keule
err := json.Unmarshal([]byte(j_a), &k)
return k, err
}
func Unmarshal_H(b []byte) (Mega, error) {
var k Hans
err := json.Unmarshal([]byte(j_a), &k)
return k, err
}
var UList = []func(b []byte) (Mega, error) {Unmarshal_H, Unmarshal_K}
func main() {
var mv Class
err := json.Unmarshal([]byte(j_a), &mv)
if err != nil {
panic(err)
}
hiho, err := UList[mv.Class]([]byte(j_a))
if err != nil {
panic(err)
}
hiho.ppp()
}
You can use it in the following way. If you give the print function one of the person or secret Agent, it will understand that it came directly from the human interface and run the function inside it.
package main
import "fmt"
type person struct {
firstName string
lastName string
age int
}
type secretAgent struct {
person
ltk bool
}
type human interface {
info() string
}
func (p person) info() string {
return fmt.Sprint("Name:", p.firstName, " Surname:", p.lastName, " Age:", p.age)
}
func (s secretAgent) info() string {
return fmt.Sprint("Name:", s.firstName, " Surname:", s.lastName, " Age:", s.age, " Ltk:", s.ltk)
}
func print(h human) {
switch h.(type) {
case person:
fmt.Println("person struct:")
fmt.Println(h.info())
case secretAgent:
fmt.Println("secretAgent struct:")
fmt.Println(h.info())
}
}
func main() {
p := person{
firstName: "Khanbala",
lastName: "Reshidov",
age: 22,
}
s := secretAgent{
person: p,
ltk: true,
}
//info Method
fmt.Println(p.info())
fmt.Println(s.info())
//polymorphism
print(p)
print(s)
//type
fmt.Printf("%T\n", p)
fmt.Printf("%T\n", s)
}
How to implement an abstract class in Go? As Go doesn't allow us to have fields in interfaces, that would be a stateless object. So, in other words, is it possible to have some kind of default implementation for a method in Go?
Consider an example:
type Daemon interface {
start(time.Duration)
doWork()
}
func (daemon *Daemon) start(duration time.Duration) {
ticker := time.NewTicker(duration)
// this will call daemon.doWork() periodically
go func() {
for {
<- ticker.C
daemon.doWork()
}
}()
}
type ConcreteDaemonA struct { foo int }
type ConcreteDaemonB struct { bar int }
func (daemon *ConcreteDaemonA) doWork() {
daemon.foo++
fmt.Println("A: ", daemon.foo)
}
func (daemon *ConcreteDaemonB) doWork() {
daemon.bar--
fmt.Println("B: ", daemon.bar)
}
func main() {
dA := new(ConcreteDaemonA)
dB := new(ConcreteDaemonB)
start(dA, 1 * time.Second)
start(dB, 5 * time.Second)
time.Sleep(100 * time.Second)
}
This won't compile as it's not possible to use interface as a receiver.
In fact, I have already answered my question (see the answer below). However, is it an idiomatic way to implement such logic? Are there any reasons not to have a default implementation besides language's simplicity?
The other answers provide an alternative to your problem, however they proposed solution without using abstract classes/struct, and I guess if you were interested in using abstract class like solution, here is very precise solution to your problem:
Go plaground
package main
import (
"fmt"
"time"
)
type Daemon interface {
start(time.Duration)
doWork()
}
type AbstractDaemon struct {
Daemon
}
func (a *AbstractDaemon) start(duration time.Duration) {
ticker := time.NewTicker(duration)
// this will call daemon.doWork() periodically
go func() {
for {
<- ticker.C
a.doWork()
}
}()
}
type ConcreteDaemonA struct {
*AbstractDaemon
foo int
}
func newConcreteDaemonA() *ConcreteDaemonA {
a:=&AbstractDaemon{}
r:=&ConcreteDaemonA{a, 0}
a.Daemon = r
return r
}
type ConcreteDaemonB struct {
*AbstractDaemon
bar int
}
func newConcreteDaemonB() *ConcreteDaemonB {
a:=&AbstractDaemon{}
r:=&ConcreteDaemonB{a, 0}
a.Daemon = r
return r
}
func (a *ConcreteDaemonA) doWork() {
a.foo++
fmt.Println("A: ", a.foo)
}
func (b *ConcreteDaemonB) doWork() {
b.bar--
fmt.Println("B: ", b.bar)
}
func main() {
var dA Daemon = newConcreteDaemonA()
var dB Daemon = newConcreteDaemonB()
dA.start(1 * time.Second)
dB.start(5 * time.Second)
time.Sleep(100 * time.Second)
}
If this is still not obvious how to use abstract classes/multi-inheritance in go-lang here is the post with comprehensive details. Abstract Classes In Go
If you want to provide a "default" implementation (for Daemon.start()), that is not the characteristic of an interface (at least not in Go). That is a characteristic of a concrete (non-interface) type.
So Daemon in your case should be a concrete type, conveniently a struct since you want it to have fields. And the task to be done can be either a value of an interface type, or in a simple case just a function value (a simple case means it would only have one method).
With interface type
Try the complete app on the Go Playground.
type Task interface {
doWork()
}
type Daemon struct {
task Task
}
func (d *Daemon) start(t time.Duration) {
ticker := time.NewTicker(t)
// this will call task.doWork() periodically
go func() {
for {
<-ticker.C
d.task.doWork()
}
}()
}
type MyTask struct{}
func (m MyTask) doWork() {
fmt.Println("Doing my work")
}
func main() {
d := Daemon{task: MyTask{}}
d.start(time.Millisecond*300)
time.Sleep(time.Second * 2)
}
With a function value
In this simple case this one is shorter. Try it on the Go Playground.
type Daemon struct {
task func()
}
func (d *Daemon) start(t time.Duration) {
ticker := time.NewTicker(t)
// this will call task() periodically
go func() {
for {
<-ticker.C
d.task()
}
}()
}
func main() {
d := Daemon{task: func() {
fmt.Println("Doing my work")
}}
d.start(time.Millisecond * 300)
time.Sleep(time.Second * 2)
}
An easy solution is to move daemon *Daemon to the argument list (thus removing start(...) from the interface):
type Daemon interface {
// start(time.Duration)
doWork()
}
func start(daemon Daemon, duration time.Duration) { ... }
func main() {
...
start(dA, 1 * time.Second)
start(dB, 5 * time.Second)
...
}
You can implement abstract class in go.
The definition:
type abstractObject interface{
print()
}
type object struct{
a int
abstractObject
}
Now object is an abstract class, like java's.
You can inherit it and use its members:
type concreteObject struct{
*object
}
(o *concreteObject) print() {
fmt.Println(o.a)
}
func newConcreteObject(o *object) {
obj := &concreteObject{object: o}
o.abstractObject = obj // all magics are in this statement.
}
And use the object with concreteObject's methods:
o := &object{}
newConcereteObject(o)
o.print()
And cast abstract object to concrete object:
concObj := o.abstractObject.(*concreteObject)
Just like other OOP languages.
The solution by Max Malysh would work in some cases if you don't need a factory. However the solution given by Adrian Witas could cause cyclic dependencies issues.
This is the way I achieved implementing an abstract class the easy way respecting cyclic dependencies and good factory patterns.
Let us assume we have the following package structure for our component
component
base
types.go
abstract.go
impl1
impl.go
impl2
impl.go
types.go
factory.go
Define the definition of the component, in this example it will be defined here:
component/types.go
package component
type IComponent interface{
B() int
A() int
Sum() int
Average() int
}
Now let's assume we want to create an abstract class that implements Sum and Average only, but in this abstract implementation we would like to have access to use the values returned by the implemented A and B
To achieve this, we should define another interface for the abstract members of the abstract implementation
component/base/types.go
package base
type IAbstractComponentMembers {
A() int
B() int
}
And then we can proceed to implement the abstract "class"
component/base/abstract.go
package base
type AbstractComponent struct {
IAbstractComponentsMember
}
func (a *AbstractComponent) Sum() int {
return a.A() + a.B()
}
func (a *AbstractComponent) Average() int {
return a.Sum() / 2
}
And now we proceed to the implementations
component/impl1/impl.go // Asume something similar for impl2
package impl1
type ComponentImpl1 struct {
base.AbstractComponent
}
func (c *ComponentImpl1) A() int {
return 2
}
func (c *ComponentImpl1) A() int {
return 4
}
// Here is how we would build this component
func New() *ComponentImpl1 {
impl1 := &ComponentImpl1{}
abs:=&base.AbstractComponent{
IAbstractComponentsMember: impl1,
}
impl1.AbstractComponent = abs
return impl1
}
The reason we use a separate interface for this instead of using Adrian Witas example, is because if we use the same interface in this case, if we import the base package in impl* to use the abstract "class" and also we import the impl* packages in the components package, so the factory can register them, we'll find a circular reference.
So we could have a factory implementation like this
component/factory.go
package component
// Default component implementation to use
const defaultName = "impl1"
var instance *Factory
type Factory struct {
// Map of constructors for the components
ctors map[string]func() IComponent
}
func (f *factory) New() IComponent {
ret, _ := f.Create(defaultName)
return ret
}
func (f *factory) Create(name string) (IComponent, error) {
ctor, ok := f.ctors[name]
if !ok {
return nil, errors.New("component not found")
}
return ctor(), nil
}
func (f *factory) Register(name string, constructor func() IComponent) {
f.ctors[name] = constructor
}
func Factory() *Factory {
if instance == nil {
instance = &factory{ctors: map[string]func() IComponent{}}
}
return instance
}
// Here we register the implementations in the factory
func init() {
Factory().Register("impl1", func() IComponent { return impl1.New() })
Factory().Register("impl2", func() IComponent { return impl2.New() })
}
The functionality of abstract class has below requirements
1. It should not be possible to create direct instance of abstract class
2. It should provide default fields and methods.
A combination of interface and struct can be used to fulfill above two requirements. For example we can see below
package main
import "fmt"
//Abstract Interface
type iAlpha interface {
work()
common(iAlpha)
}
//Abstract Concrete Type
type alpha struct {
name string
}
func (a *alpha) common(i iAlpha) {
fmt.Println("common called")
i.work()
}
//Implementing Type
type beta struct {
alpha
}
func (b *beta) work() {
fmt.Println("work called")
fmt.Printf("Name is %s\n", b.name)
}
func main() {
a := alpha{name: "test"}
b := &beta{alpha: a}
b.common(b)
}
Output:
common called
work called
Name is test
One important point to mention here is that all default method should have iAlpha as first argument, and if default method needs to call any unimplemented method they they will call on this interface. This is same as we did in common method above - i.work().
Source: https://golangbyexample.com/go-abstract-class/
I have a simple method, which just checks if a parameter is empty and then calls one of 2 methods based on a struct field.
How would I test it?
func (cT *customType) someMethod(message string) {
if message == ""{
return
}
if cT.value == nil {
cT.doFunctionOne()
} else {
cT.doFunctionTwo()
}
}
In Javascript, I would create a spy on doFunctionOne() and mock up the object.
Mocking up works well in Go as well, but how would I do the 'spying' part?
Or is there another idiomatic way to test this kind of method?
First: You wouldn't name a method "doFunctionOne" but "methodOne" :-)
If neither doFunctionOne nor doFunctionTwo has any observable effect, then there is absolutely no point in testing it. So we may assume that they do have observable side effect, either on the environment or on the customType they have been invoked on.
Now just test these side effects. This is trivial if both methods do return. If they spin up an endless loop it becomes harder, but still doable.
IMHO there is no need to "test" this method in the sense of "test whether it calls One or Two depending on value": For me this is to lowlevel, too much increasing coverage count for nothing. If you call some method it has to do something (observable effect) and you should check this effect, not the inner workings.
The idiomatic way of mocking an object in Go is to make it explicit. A healthy interface should be testable by itself. So if we have something like this:
type customType struct {
value int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) someMethod() {
if c.value <= 0 {
c.doFunctionOne()
} else {
c.doFunctionTwo()
}
}
We have to provide a way to change the implementation of doFunctionOne and doFunctionTwo explicitly. We can generalize the someMethod behavior using interfaces:
type customType struct {
myValue int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) value() int {
return c.myValue
}
type Interface interface {
value() int
doFunctionOne()
doFunctionTwo()
}
func someMethod(i Interface) {
if i.value() <= 0 {
i.doFunctionOne()
} else {
i.doFunctionTwo()
}
}
type customTestingType struct {
t *testing.T
}
func (c customTestingType) doFunctionOne() {
c.t.Log("Working")
}
func (c customTestingType) doFunctionTwo() {
c.t.Error("Not working")
}
func (c customTestingType) value() int {
return 0
}
func TestInterface(t *testing.T) {
someMethod(customTestingType{t})
}
Surely there will be more ways to provide this behavior but it depends on the particular declaration of your type. As an example, you can look at httptest package. That said, if you really want to mock your type in that way (nonidiomatic), you can some unsafe monkey patching:
package main
import (
"fmt"
"reflect"
"github.com/bouk/monkey"
)
type customType struct {
myValue int
}
func (c customType) doFunctionOne() {
fmt.Println("Method #1")
}
func (c customType) doFunctionTwo() {
fmt.Println("Method #2")
}
func (c customType) someMethod() {
if c.myValue <= 0 {
c.doFunctionOne()
} else {
c.doFunctionTwo()
}
}
func main() {
c := customType{0}
monkey.PatchInstanceMethod(reflect.TypeOf(c), "doFunctionOne",
func(c customType) {
fmt.Println("Method #1, but patched")
})
monkey.PatchInstanceMethod(reflect.TypeOf(c), "doFunctionTwo",
func(c customType) {
fmt.Println("Method #2, but patched")
})
c.someMethod()
}
You can add log before each function call.
Inject your own logger implementation, []string for example.
Check the string slice for a matching strings.
But, if you are creating a function factory it would be better if you return the function to the caller and the caller will run the function.
Then testing is straightforward.
Second but, there is only two kind of functions, flow function and logic functions.
You mixed flow and logic in the same function.
Testing difficulty is just one symptom of this bad practice.