Q:

When to use Encapsulate Collection?

In the smell Data Class as Martin Fowler described in Refactoring, he suggests if I have a collection field in my class I should encapsulate it. 
The pattern Encapsulate Collection(208) says we should add following methods:

get_unmodified_collection
add_item
remove_item

and remove these:

get_collection
set_collection

To make sure any changes on this collection need go through the class.
Should I refactor every class which has a collection field with this pattern? Or it depends on some other reasons like frequency of usage? 
I use C++ in my project now.
Any suggestion would be helpful. Thanks.

A:

These are well formulated questions and my answer is:

Should I refactor every class which has a collection field with this
  pattern? 

No, you should not refactor every class which has a collection field. Every fundamentalism is a way to hell. Use common sense and do not make your design too good, just good enough.

Or it depends on some other reasons like frequency of usage?

The second question comes from a common mistake. The reason why we refactor or use design pattern is not primarily the frequency of use. We do it to make the code more clear, more maintainable, more expandable, more understandable, sometimes (but not always!) more effective. Everything which adds to these goals is good. Everything which does not, is bad.

You might have expected a yes/no answer, but such one is not possible here. As said, use your common sense and measure your solution from the above mentioned viewpoints.

I generally like the idea of encapsulating collections. Also encapsulating plain Strings into named business classes. I do it almost always when the classes are meaningful in the business domain. 
I would always prefer
public class People {
    private final Collection<Man> people;
    ... // useful methods
}

over the plain Collection<Man> when Man is a business class (a domain object). Or I would sometimes do it in this way:
public class People implements Collection<Man> {
    private final Collection<Man> people;

    ... // delegate methods, such as
    @Override
    public int size() {
        return people.size();
    }
    @Override
    public Man get(int index) {
        // Here might also be some manipulation with the returned data etc.
        return people.get(index);
    }
    @Override
    public boolean add(Man man) {
        // Decoration - added some validation
        if (/* man does not match some criteria */) {
            return false;
        }
        return people.add(man);
    }

    ... // useful methods
}

Or similarly I prefer 
public class StreetAddress {
    private final String value;
    public String getTextValue() { return value; }
    ...
    // later I may add more business logic, such as parsing the street address
    // to street name and house number etc.
}

over just using plain String streetAddress - thus I keep the door opened to any future change of the underlying logic and to adding any useful methods.
However, I try not to overkill my design when it is not needed so I am as well as happy with plain collections and plain Strings when it is more suited.

