Refactor Go Package by Using gomvpkg

Ball Weera Kasetsin — Wed, 24 Apr 2019 02:08:44 +0000

https://blog.golang.org/gopher

Go provides a lot of tools to help Go developers. They help Go developers to be productive when they are trying to solve their problems with Go. You can see the list of tools at https://godoc.org/golang.org/x/tools

I've seen many developers that moved from other technology stacks (Java Spring, Ruby on Rails, etc.) use the previous project structure from those to Go project. Layer-based is the one example (controller, model, service, common, util, repository, etc.). In Go, mostly, we will not do that. When we design a Go package (structure), we think about what it provides, not what it contains. And how we use them. You can read my blog about Go Package (Structure) Design

As you may know, it is painful when you are trying to refactor legacy Go package. Especially, packages like common, util, base. Because it has been used around the project (other packages use them by importing). If you refactor those packages, you need to put a lot of effort to change the import path in every derived package.

Actually, there is a Go tool for this situation. It is gomvpkg.https://godoc.org/golang.org/x/tools/cmd/gomvpkg

I'm going to show you how to refactor legacy Go package by using gomvpkg. We have the package common/consumer.

You can see that github.com/ballweera/play-gomvpkg/common/consumer has been used in only two places (event.go and main.go). But in a large program, it may be used more than 10 or 20 times. So it is a bit difficult to refactor and take time to refactor them.

By using gomvpkg, we can execute only one command to change from github.com/ballweera/play-gomvpkg/common/consumer to github.com/ballweera/play-gomvpkg/kafka

After executing gomvpkg, you would see the result like this

Now, in event.go and main.go, the import path is changed to github.com/ballweera/play-gomvpkg/kafka.

One thing you need to know about gomvpkg. It could not be run outside GOPATH. So you need to move your Go project to GOPATH before using it. And if you use Go Module (go.mod), you also need to set GO111MODULE=auto.

I already created the repo to play the gomvpkg https://github.com/ballweera/play-gomvpkg.

Have fun!!

Go Package (Structure) Design

Ball Weera Kasetsin — Tue, 23 Apr 2019 02:39:23 +0000

Photo by Leone Venter on Unsplash

Good package name tells you what it provides, not what it contains
-- Practical Go, Dave Cheney

I do believe in User-Centric Design. It is not only about UX/UI. It is about how things will be used. So when I create functions, programs, APIs, I always think about how to use them. And this is why I love Test-Driven Development (TDD) methodology as well because it encourages me to think about how my function will be used (with tests).

The package is the unit in a Go program that other packages or modules use it. When I create a package, I'll ask how this package will be used.

In Go, we always use functions through the package.

The package name is essential in Go. So this is the guideline,

The package name must be unique in your Go program

If you have found that packages name have been used multiple time in your Go program, those packages would be too generic, or there is some design problem that needs to validate.

To demonstrate creating a Go package, think about shopping cart on e-commerce. I'm going to provide "add to cart" function. I've started with the cart package.

When you create a Go package, always put Go file with the same name as a package name.

Every time I create a new package, I always put Go file with the same name as the package name. And I'll maintain all functionality of this package in this Go file until I understand the boundary of this package, then use another Go files to re-organize this package. If some feature doesn't make sense to be in this package, I'll move it to a new package.

From the code snippet, two entities need to consider; Cart and Product. Cart is the receiver of Add method, so I create Cart struct. And also generate Product struct. From this point, I create the "New" function that will return a Cart.

When you want a cart, you can call New function.

c := cart.New()

It is quite natural and readable in my point of view.

Think about creating a new product. You would have seen pd := cart.NewProduct(). As I mentioned, the package name will tell you what it provides. From my perspective, the cart should not be responsible for proving the product's functionality. So I decided to create a new package; product and move Product to a new one. When you want to create a product, you can call New function from the product package like pd := product.New()

Keep using Go file to re-organize your package, use sub-package when it makes sense

In the Go program, mostly, we don't call a package function with package chaining like this; net.http.Get("http://www.example.com"). So we need to keep the package name being unique in the Go program. We can create sub-package if it is reasonable. the net/http is an excellent example for sub-package.

So when you want to re-organize data in your package, you can use Go file to group related data and function and give the meaningful name to a file. Let's see this example

common/kafka/producer
common/kafka/consumer

From that design, when you want to create a producer or a consumer, you will use pdc := producer.New() and csm := consumer.New()

It seems to be OK. But it loses the context. What do the producer and consumer mean?

One thing I want to mention is

Avoid package name like base, common, or util

Those packages are too generic. If there is something you would reuse, you will put them to those packages. And then the package name cannot tell you what it provides.

So I decide to refactor the above package to this

Then you can create a producer and consumer with pdc := kafka.NewProducer() and csm := kafka.NewConsumer()

When you face that your package keeps growing, you can use Go file to re-organize data and functionality. From the previous example, I'll create producer.go and consumer.go to organizer data and functionalities of a producer and a consumer instead of creating sub-package.

Most of the time, I don't design all packages of Go program in the first place. But I will think about how the package will be used and what it should provide.

I hope you will have fun to create software that improves our user's life gets better.

Forem: Ball Weera Kasetsin

Refactor Go Package by Using gomvpkg

Go Package (Structure) Design

In Go, we always use functions through the package.

Keep using Go file to re-organize your package, use sub-package when it makes sense