> > I've been reading the other day: "having a model package, is considered a > code smell, in Go". > > 1 - Why? >
Assuming you are following the Model-View-Controller you will have to export your full data model in model, so that controller and view can have access to it. But then every other package has access to your model, you cannot change the model without breaking other packages importing it. You may mitigate that a little bit by making the model an internal package, but still all your own packages importing it may break. 2 - If so, what approach should be chosen? > A lot depends on the specific situation, but in general try to minimize the exported functions to the set that is required to support a defined use case. Antoine de Saint-Exupery wrote about airplanes: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." That is good principle to apply to API design and the exported symbols of a package are an API. I also recommend this ten-year old talk by Joshua Bloch about API design: https://youtu.be/aAb7hSCtvGw > 3 - And how? (In Go code, Go features to employ, Patterns (small/big > projects), etc) > If you are using an Model-View-Controller model expose the view and control function or methods. Think twice before you are creating a new package. A package should group functionality not separate it. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
