Спасибо за фидбек, мне очень интересно знать как воспринимается контент. Буду рад, если вы будете постить и другие мысли.
Я, правда, не совсем понимаю в чем именно загвоздка. Было бы клёво, если бы вы прояснили. В примере с мостом БЫЛО это расширение фигур через наследование. СТАЛО это внедрение цветов через композицию.
Может в БЫЛО непонятно зачем мы вообще расширяем иерархию по цвету? Или непонятно что расширение через наследование это и есть БЫЛО?
Возможно пример с фигурами запутывает. Не ясно почему мы "хотим расширить иерархии по цвету". Цвет как характеристика сразу воспринимается как свойство суперкласса Фигура. А вот "тип фигуры" в виде "Квадрат" и "Треугольник" как раз легко понимается как наследник, а не как свойство, хотя и эта характеристика может быть свойством. Другой пример, возможно, не дал бы такой путаницы.
Именно благодаря этому, после прочтения, хотелось бы посмотреть на реальный кэйс проблемы или задачи, который мы решаем в виде исходного кода. Желание иметь пример БЫЛО (до использования паттерна, или его незнание) возникало и в других статьях о паттернах. Например, из статьи о паттерне "Prototype":
> Не каждый объект удастся скопировать таким образом, ведь часть его состояния может быть приватной и недоступна для остального кода программы
Такие описания хорошо бы снабжать примерами.
Часто читая примеры, видишь как все красиво, и уже не помнишь а в чем же была проблема, или как можно было по-другому.
Предложение состоит не столько в тексте, как в добавлении примеров "кода до применения паттерна". Потом произвели рефакторинг, и получили "код после применения паттерна".
Последнее я называю "рефакторинг к паттерну" и планирую сделать такой раздел в виде расширения секции рефакторинга в будущем. Возможно, короткие до-после добавлю на страницы паттернов, но это будет видно позже.
Идеи
Спасибо за фидбек, мне очень интересно знать как воспринимается контент. Буду рад, если вы будете постить и другие мысли.
Я, правда, не совсем понимаю в чем именно загвоздка. Было бы клёво, если бы вы прояснили. В примере с мостом БЫЛО это расширение фигур через наследование. СТАЛО это внедрение цветов через композицию.
Может в БЫЛО непонятно зачем мы вообще расширяем иерархию по цвету? Или непонятно что расширение через наследование это и есть БЫЛО?
Возможно пример с фигурами запутывает. Не ясно почему мы "хотим расширить иерархии по цвету". Цвет как характеристика сразу воспринимается как свойство суперкласса Фигура. А вот "тип фигуры" в виде "Квадрат" и "Треугольник" как раз легко понимается как наследник, а не как свойство, хотя и эта характеристика может быть свойством. Другой пример, возможно, не дал бы такой путаницы.
Именно благодаря этому, после прочтения, хотелось бы посмотреть на реальный кэйс проблемы или задачи, который мы решаем в виде исходного кода.
Желание иметь пример БЫЛО (до использования паттерна, или его незнание) возникало и в других статьях о паттернах. Например, из статьи о паттерне "Prototype":
> Не каждый объект удастся скопировать таким образом, ведь часть его состояния может быть приватной и недоступна для остального кода программы
Такие описания хорошо бы снабжать примерами.
Часто читая примеры, видишь как все красиво, и уже не помнишь а в чем же была проблема, или как можно было по-другому.
Спасибо, думаю, я понял, что вы имеете в виду. Подумаю как можно изменить текст.
Предложение состоит не столько в тексте, как в добавлении примеров "кода до применения паттерна". Потом произвели рефакторинг, и получили "код после применения паттерна".
Последнее я называю "рефакторинг к паттерну" и планирую сделать такой раздел в виде расширения секции рефакторинга в будущем. Возможно, короткие до-после добавлю на страницы паттернов, но это будет видно позже.