Здравствуйте, Sinclair, Вы писали:
S>>Т.е нужен фрагмент кода, который подтверждал бы Ваш тезис, и невозможность как-то его изменить, что подтверждало бы S>>тезис про ненастраиваемость. В ответ -- уход от темы про способы реализации декоратора, и прочая обычная для Вас кака-бяка.
S>Ну вот смотрите, какая штука. S>Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста. S>И вот вам захотелось иметь возможность репортить ошибки с привязкой к строка/позиция, а не просто "character #2213123". S>Как вы это будете делать? Отнаследуетесь от SteamReader? Отнаследуетесь от TextReader? Сделаете свой класс, не отнаследованный ни от чего? S>Какие методы придётся перекрыть? Какие — не придётся?
Скорее всего унаследуюсь от TR, но агрегирую SR, ибо надо позицию учитывать. Как-то так.
S>Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.
