Ah well, we can't all invent something new.
Anyway, the refactoring in question is "Replace Array With Object", though I've been seeing "Replace List With Object". I first encountered this in C#, and recently again in C++. The method for doing this refactoring I feel is more elegant than in Java or C (or Go for that matter), though primarily because Lists in C# and C++ have array-like syntax available, whereas in Java they do not.
Consider a naive data-structure which represents the "nuclear family":
enum Parents {
  DAD_INDEX = 0,
  MOM_INDEX = 1
};
list<Person> family = GetFamilyMembersParentsFirst();
Person dad = family[DAD_INDEX];
Person mom = family[MOM_INDEX];
int numChildren = family.size() - 2;
Then the client does this:
How will we handle families with more or less than one parent, or same-sex parents?
Replace List With Object to the rescue!! We need a class which represents the family as a unit. So, first off let's subclass list
class Family: public list<Person>
{
}
Now, change GetFamilyMembersParentsFirst() to return a Family instead of a list<Person>:
Family GetFamilyMembersParentsFirst() {...}
Now, we can change the client to use Family:
enum Parents {
  DAD_INDEX = 0,
  MOM_INDEX = 1
};
Family family = GetFamilyMembersParentsFirst();
Person dad = family[DAD_INDEX];
Person mom = family[MOM_INDEX];
int numChildren = familiy.size() - 2;
Finally, we can start adding behaviors, like GetNumChildren(). This can be done by extracting the relevant behavior from the client code and moving it to the Family class:
class Family: public list<Person>
{
public:
    int GetNumChildren()
    {
        return size() - 2;
    }
}
...
Family family = GetFamilyMembersParentsFirst();
...
int numChildren = family.GetNumChildren();
Now Family can answer our questions about a given family unit. Hooray!
Now, let's take care of those pesky 'mom' and 'dad' variables. Since we're not changing how the class works yet, we'll just extract 'family[DAD_INDEX]' and 'family[MOM_INDEX]' to functions, and move them to the Family class:
class Family: public list<Person>{
public:
     Person Dad()
     {
         return (*this)[DAD_INDEX];
     }
     Person Mom()
     {
         return (*this)[MOM_INDEX];
     }
}
...
Family family = GetFamilyMembersParentsFirst();
Person dad = family.Dad();
Person mom = family.Mom();
int numChildren = family.GetNumChildren();
Hey, now we can add setters:
class Family: public list<erson>
{
private:
    Person dad;
    Person mom;
    list<Person> children;
public:
    void Dad(Person dad) { this->dad = dad; }
    void Mom(Person mom) { this->mom = mom; }
    void AddChild(Person child) { children.push_back(child); }
    ...
}
And use them within GetFamilyMembersParentsFirst():
Family GetFamilyMembersParentsFirst()
{
    Family family;
    ...
    family.Dad(GetMaleTaxPayer());
    family.Mom(GetFemaleTaxPayer());
    ...
}
Finally, we can change Family to not subclass list<Person>:
class Family
{
...
}
And everything still compiles and works! (Exactly what we would expect out of a good refactoring.)
 
