Learning when to use core classes

Let's consider the following Ruby code:

things = ["foo", "bar", "baz"]
things.each do |thing|
  puts thing
end

If you have come across this code, then you probably have an immediate understanding of what the code does. However, let's say you come across the following Ruby code:

things = ThingList.new("foo", "bar", " baz")
things.each do |thing|
  puts thing
end

You can probably guess what it does, but to be sure, you need to know about the ThingList class and how it is implemented. What does ThingList.new do? Does it use its arguments directly or does it wrap them in other objects? What does the ThingList#each method yield? Does it yield the same objects passed into the constructor, or other objects? When you come across code like this, your initial assumption may be that it would yield other objects and not the objects passed into the constructor, because why else would you have a class that duplicates the core Array class?

A good general principle is to only create custom classes when the benefits outweigh the costs. When deciding whether to use a core class or a custom class, you should understand the trade-off you are making. With core classes, your code is often more intuitive, and in general will perform better, since using core classes directly results in less indirection. With custom classes, you are able to encapsulate your logic, which can lead to more maintainable code in the long term, if you have to make changes. In many cases, you won't have to make changes in the future, and the benefits of encapsulation are not greater than the loss of intuition and performance. If you aren't sure whether to use a custom class or a core class, a good general principle is to start with the use of core classes, and only add a custom class when you see a clear advantage in doing so.