Q:

"Collection Wrapper" pattern - is this common?

A different question of mine had to do with encapsulating member data structures inside classes. In order to understand this question better please read that question and look at the approach discussed.
One of the guys who answered that question said that the approach is good, but if I understood him correctly - he said that there should be a class existing just for the purpose of wrapping the collection, instead of an ordinary class offering a number of public methods just to access the member collection.
For example, instead of this:
class SomeClass{

    // downright exposing the concrete collection.        

    Things[] someCollection;

   // other stuff omitted

    Thing[] getCollection(){return someCollection;}

}

Or this:
class SomeClass{

    // encapsulating the collection, but inflating the class' public interface.

    Thing[] someCollection;

    // class functionality omitted.

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}

We'll have this:
// encapsulating the collection - in a different class, dedicated to this.

class SomeClass{
    CollectionWrapper someCollection;

    CollectionWrapper  getCollection(){return someCollection;}
}

class CollectionWrapper{

    Thing[] someCollection;

    public Thing getThing(int index){
        return someCollection[index];
    }

    public int getSize(){
        return someCollection.length;
    }

    public void setThing(int index, Thing thing){
        someCollection[index] = thing;
    }

    public void removeThing(int index){
        someCollection[index] = null;
    }

}

This way, the inner data structure in SomeClass can change without affecting client code, and without forcing SomeClass to offer a lot of public methods just to access the inner collection. CollectionWrapper does this instead.
E.g. if the collection changes from an array to a List, the internal implementation of CollectionWrapper changes, but client code stays the same.
Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.
This approach to decoupling client code from the concrete data structure seems IMHO pretty good.
Is this approach common? What are it's downfalls? Is this used in practice?

A:

You are implementing a restricted set of the Collection interface, without actually giving it something that you can work with.

E.g. if the collection changes from an array to a List, the internal 
  implementation of CollectionWrapper changes, but client code stays the same.

This is exactly what the Collection interface is intended to do.  If you pass back a Collection, that is all the client can work from.

Also, the CollectionWrapper can hide certain things from the client code - from example, it can disallow mutation to the collection by not having the methods setThing and removeThing.

In Java, this is known as an Unmodifiable Collection, and the Collections utility has just such a method to convert a modifiable collection to an unmodifiable one.
By making the restricted wrapper you are also giving up things such as sort and iterator which come in very handy from time to time.  This means code such as:
for(Thing t : someCollection) {
    ....
}

won't work.  Instead, the code would need to be:
for(int i = 0; i < someCollection.size(); i++) {
    Thing t = someCollection.get(i);
    ....
}

While that is perfectly acceptable code, it also means you are failing to take advantage of the language to allow the client to write code faster (programmer time is expensive).
The way you decouple the implementation is to use an interface, preferably one that already exists in the language framework so that other things that use that same interface can use your code without jumping through additional hoops.

Just a note:

What I'm trying to do, is not expose the collection - because I don't want the client code to break when the collection changes say from a List to a Set. If I just allow the client code to do class.getCollection() it'll break when the type of the collection changes. So the idea is to make a thin layer around it ("CollectionWrapper"), so when the type of collection changes, only the wrapper has to change, but not the code using the collection (i.e. using the wrapper). Is what I'm saying clear?

If the collection is only given as a Collection interface, it won't break.  However, I must point out that the public methods that you are presenting with this class, namely public Thing getThing(int index), public void setThing(int index, Thing thing), and public void removeThing(int index) would preclude the implementation from changing from a List to a Set, because Sets have no concept of indexes and these methods would need to change.

