История изменений

Важно другое: в данном примере вы не добились чего-то добавив пару строк, вы серьёзно ухудшили программу, многое поломав, написав лишние десятки строк и не добавив ничего. Единственная ценность такого кода - демонстрация крутизны наследования. Давайте представим, что мы делаем что-то полезное. Например добавляем indent к классу tree_view, который его сам по себе не поддерживает. И мы по какой-то причине не можем обернуть его в другой виджет, просто добавляющий indent. Можно ли такое в плюсах с наследованием? Да, если все нужные методы виртуальны. Вы добавите сдвиг в функции рисования. Вы добавите что-то к результату базового вычисления размера. Во всех обработчиках событий мыши добавите сдвиг координат. И это будет работать. Ваш коллега растовик с его декоратором сделает то же самое, но кода у него будет в 2 раза больше. Однако должен заметить, что половина кода от декоратора - это уже не «2 строки» и выгода не столь уж очевидна. Но самый цимес начнётся, когда в вашем проекте обновится библиотека гуи. Добавится, например, баблинг событий мыши. У растовика сломается сборка, а у вас просто начнутся глюки от того что половина обработки мыши базовым классом не совпадает по координатам с другой, которую вы не переопределили.

у вас крышка едет реально и вы не понимаете существо вопроса. повторяю еще раз.

у вас есть готовый виджет и вы не можете его менять никак. но вам хочется иметь его конкретизацию, для определенных целей. например это не просто tree_view, а tree_view c дополнительными свойствами. у него есть меню, откуда можно эти свойства например поюзать. в данном конкретном вымышленном искусственном примере - есть дефолтный отступ и его можно восстановить выбрав пункт меню. чтобы такое реализовать, я отнаследовал tree_view и добавил свое поле. и целиком и полностью решил вопрос за 5 строк.

поле я ввел специально, чтобы вы не могли написать обертку конструктору. а были вынуждены писать хоть какой-то класс, чтобы это поле хранить. вот и все.

как будете этот вопрос решать вы со своими трейтами?

Важно другое: в данном примере вы не добились чего-то добавив пару строк, вы серьёзно ухудшили программу, многое поломав, написав лишние десятки строк и не добавив ничего. Единственная ценность такого кода - демонстрация крутизны наследования. Давайте представим, что мы делаем что-то полезное. Например добавляем indent к классу tree_view, который его сам по себе не поддерживает. И мы по какой-то причине не можем обернуть его в другой виджет, просто добавляющий indent. Можно ли такое в плюсах с наследованием? Да, если все нужные методы виртуальны. Вы добавите сдвиг в функции рисования. Вы добавите что-то к результату базового вычисления размера. Во всех обработчиках событий мыши добавите сдвиг координат. И это будет работать. Ваш коллега растовик с его декоратором сделает то же самое, но кода у него будет в 2 раза больше. Однако должен заметить, что половина кода от декоратора - это уже не «2 строки» и выгода не столь уж очевидна. Но самый цимес начнётся, когда в вашем проекте обновится библиотека гуи. Добавится, например, баблинг событий мыши. У растовика сломается сборка, а у вас просто начнутся глюки от того что половина обработки мыши базовым классом не совпадает по координатам с другой, которую вы не переопределили.

у вас крышка едет реально и вы не понимаете существо вопроса. повторяю еще раз.

у вас есть готовый виджет и вы не можете его менять никак. но вам хочется иметь его конкретизацию, для определенных целей. например это не просто tree_view, а tree_view c дополнительными свойствами. у него есть меню, откуда можно эти свойства например поюзать. в данном конкретном вымышленном искусственном примере - есть дефолтный отступ и его можно восстановить выбрав пункт меню. чтобы такое реализовать, я отнаследовал tree_view и добавил свое поле. и целиком и полностью решил вопрос за 5 строк.

как будете этот вопрос решать вы со своими трейтами?