[Go language] avoid excessive refactoring

This is a creation in Article, where the information may have evolved or changed.

A question was raised on golang-nuts [1], asking how to reduce the repetition code of two similar data structures and algorithms. In short, there are two struct:quickfindset and Quickunionset, each with count, isconnected, Find, and Union methods. He found that the implementations of some of the two struct's functions were the same, so he wanted to eliminate the duplicated code.

Quick-findtype quickfindset struct {numofcomponents uint items []uint} func Newset (n uint) Quickfindset { Set: = quickfindset{numofcomponents:n, Items:make ([]uint, N)} for I, _: = Range Set.items {Set.items[i] = UINT (i)} return set} func (set *quickfindset) Count () UINT {return set.numofcomponents} func (set *quickfin DSet) isconnected (p, q uint) bool {return set. Find (p) = = set.  Find (Q)} func (set *quickfindset) Find (p uint) UINT {return set.items[p]} func (set *quickfindset) Union (p, q uint) {ROOTP: = set. Find (P) ROOTQ: = set.             Find (q) If Rootp = = ROOTQ {return} for I, _: = Range Set.items {if set.items[i] = = ROOTP {  Set.items[i] = ROOTQ}} set.numofcomponents--}//weighted quick-uniontype quickunionset struct {numofcomponents UINT items []uint sizes []uint} func Newset (n uint) Quickunionset {set: = Quickunionset {numofcomponents:n, Items:make ([]uint, N), Sizes:make ([]uint, N)} for I, _: = Range Set.items {set.items[i] = uint (i) set.sizes[i] = UINT (1)} return set} func (set *quickunionset) Count () UINT {return set.numofcomponents} func (set *quicku Nionset) isconnected (p, q uint) bool {return set. Find (p) = = set. Find (Q)} func (set *quickunionset) Find (p uint) UINT {for P! = set.items[p] {p = set.items[p]} retu RN P} func (set *quickunionset) Union (p, q uint) {ROOTP: = set. Find (P) ROOTQ: = set. Find (q) If Rootp = = ROOTQ {return} if SET.SIZES[ROOTP] < SET.SIZES[ROOTQ] {SET.ITEMS[ROOTP ] = ROOTQ SET.SIZES[ROOTQ] + = SET.SIZES[ROOTP]} else {SET.ITEMS[ROOTQ] = ROOTP Set.sizes[roo TP] + = Set.sizes[rootq]} set.numofcomponents--}

As you can see, the Quickfindset and Quickunionset count and the isconnected function are implemented the same way:

func (set *QuickFindSet) Count() uint {    return set.numOfComponents}func (set *QuickFindSet) IsConnected (p, q uint) bool {    return set.Find(p) == set.Find(q)}func (set *QuickUnionSet) Count() uint {    return set.numOfComponents}func (set *QuickUnionSet) IsConnected (p, q uint) bool {    return set.Find(p) == set.Find(q)}

The author says he always wants to eliminate repetitive code when programming, and in other languages it can be done with class or macro, and he wants to know how to do better in the go language.
in fact, here's another question: Is there a need for refactoring to eliminate duplicate code? Or, what kind of situation requires refactoring code?
I think the following conditions need to be met at the same time to refactor the code:

the code is so confusing that it's hard to read
There are requirements or potential needs to modify the code

and compare the code here:

the code that repeats here is very small, with only a few lines of code. The code structure is also relatively clear.
as a basic data structure with little association with business logic, the need for change is minimal.

So my conclusion is this: the code here does not need to be refactored, eliminating the need to eliminate the few lines of duplicate code.
Others have commented from another perspective:
The reduction of repetitive code for these algorithms also means that they are more tightly coupled, and if one of these algorithms needs to be modified later, it will affect other implementations of the algorithm, while certain repetitive code can maintain their independence.

Russ Cox also gives a similar opinion:
It is true that in other languages an abstract class with virtual methods can be used to eliminate such a small duplication of code, but it also binds the two algorithms implementations that have little in common. The benefits of keeping the standalone code far outweigh the convenience of reducing the one or two lines of repetitive code. (It is true if the other languages) one could use ' abstract classes with virtual methods ' to eliminate this minor duplic ation, but it would also tie together the implementations that really has very little in common. The benefits of keeping separate things separate far outweighs the minor convenience of avoiding a duplicated line or both. )

Finally, my concluding remarks are:
Everything has a degree, how to avoid excessive reconstruction? Perhaps we can think about the motives and results of refactoring, not just refactoring for refactoring.