Yes , cycle import is a bad design. But as the software becomes larger , not everything is controllable. In real project , some times it is a great risk to do refactor.
在 2017年1月13日星期五 UTC+8下午5:56:48，rog写道： > > On 13 January 2017 at 07:44, hui zhang <fastf...@gmail.com <javascript:>> > wrote: > > 4 Can not Cycle import. > > In my opinion, this is one of Go's really great features. When software > becomes > larger, there is huge pressure to create cyclic dependencies between > packages. > Once you start to get cyclic dependencies, the system as a whole tends > inevitably > to gather into a giant "ball of mud". That makes everything less > modular and much > harder to refactor. > > There are so many times that I would have created a cyclic dependency > rather > than spending a day or two teasing out the dependencies into something > non-cyclic. > This process almost always creates something better engineered than before > with a better separation of concerns. > > Also, as Egon says, there's a good technical reason: the Go > initialisation order depends > fundamentally on non-cyclic imports - there's no way to see an > imported package's initialised > global variables in an uninitialised state. > -- 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.
