It is definitely a neat trick. However, exposing pointers still makes direct access to data available, so it only buys you limited additional flexibility for future changes. Also, Go conventions do not require you to always put an abstraction in front of your data attributes.
Taking those things together, I would tend towards one extreme or the other for a given use case: either a) just make a public attribute (using embedding if applicable) and pass concrete types around or b) if exposing the data seems to complicate some implementation change you think is likely, expose it through methods. You’re going to be weighing this on a per-attribute basis.
If you’re on the fence, and the interface is only used within your project, maybe lean towards exposing a bare attribute: if it causes you trouble later, refactoring tools can help you find all the references to it to change to a getter/setter.
Hiding properties behind getters and setters gives you some extra flexibility to make backwards-compatible changes later. Say you someday want to change
Person to store not just a single “name” field but first/middle/last/prefix; if you have methods
Name() string and
SetName(string), you can keep existing users of the
Person interface happy while adding new finer-grained methods. Or you might want to be able to mark a database-backed object as “dirty” when it has unsaved changes; you can do that when data updates all go through
SetFoo() methods. (You could do it other ways, too, like stashing the original data somewhere and comparing when a
Save() method is called.)
So: with getters/setters, you can change struct fields while maintaining a compatible API, and add logic around property get/sets since no one can just do
p.Name = "bob" without going through your code.
That flexibility is more relevant when the type is complicated (and the codebase is big). If you have a
PersonCollection, it might be internally backed by an
uint of database IDs, or whatever. Using the right interface, you can save callers from caring which it is, the way
io.Reader makes network connections and files look alike.
One specific thing:
interfaces in Go have the peculiar property that you can implement one without importing the package that defines it; that can help you avoid cyclic imports. If your interface returns a
*Person, instead of just strings or whatever, all
PersonProviders have to import the package where
Person is defined. That may be fine or even inevitable; it’s just a consequence to know about.
But again, the Go community does not have a strong convention against exposing data members in your type’s public API. It’s left to your judgment whether it’s reasonable to use public access to an attribute as part of your API in a given case, rather than discouraging any exposure because it could possibly complicate or prevent an implementation change later.
So, for example, the stdlib does things like let you initialize an
http.Server with your config and promises that a zero
bytes.Buffer is usable. It’s fine to do your own stuff like that, and, indeed, I don’t think you should abstract things away preemptively if the more concrete, data-exposing version seems likely to work. It’s just about being aware of the tradeoffs.