Объясните запрещенное наследование через доменные измерения представления/реализации vs семантика

Если я правильно понял, в блоге уже есть примеры, которые показывают, что имеет в виду автор. Возьмите класс домена CustomerGroup. Когда мы устанавливаем нашу точку зрения на то, как реализовать такой класс, он может быть получен из ArrayList<Customer>. Однако, когда мы сосредоточимся на моделировании предметной области («семантике»), CustomerGroup является DemographicSegment, следовательно, он также может наследовать этот класс. Здесь может возникнуть соблазн использовать множественное наследование или (в таких языках, как Java или C#), одиночное наследование плюс наследование интерфейса. Исходя из собственного опыта, я согласен со Стивеном Лоу в том, что обычно это не очень хорошая идея и рано или поздно вызовет проблемы.

Следовательно, автор рекомендует решать такие проблемы проектирования путем отделения «измерения реализации» от «семантического измерения». CustomerGroup может быть представлен ArrayList<Customer> с помощью переменной-члена этого типа («композиция вместо наследования»). Это позволит CustomerGroup быть дочерним классом DemographicSegment, так что останется только один вид наследования. Если вы все еще склонны делать производные от ArrayList<Customer> (возможно, вы хотите переопределить некоторые технические методы для отладки, хэширования или чего-то еще), альтернативой может быть введение вспомогательного класса, давайте назовем его ListOfCustomers, который является производным от ArrayList<Customer> и существует исключительно для ради реализации. Тогда CustomerGroup можно реализовать, используя ListOfCustomers (конечно, по композиции).