Цитата:
Сообщение от
mazzy
в теории конечно да.
но на практике получаются бесконечные *Adapter, *Handler, *Helper, *Util и прочие расширители.
*Adapter - чем плох? Название говорящее.
*Handler - это действительно непонятно.
*Helper, *Util - лучше класть в тот класс, в котором, собственно, предмет обработки, но если класс чужой а твои методы для него очень специфичны либо это не класс, а интерфейс, то чем плохо положить в *Util? Только надо выбрать один из этьи суффиксов, что в MS не сделано, к сожалению.
Цитата:
тот же *Print здорово сбивает с толку, если в результате расширения функционал "печати" стал еще и отсылать куда-то email, обращаться к внешним EDI сервисам, или записывать что-то в базу данных...
Печать тоже не печатает, а иногда выводит для предварительного просмотра. Возможно стоило назвать Output, например.
Цитата:
а если эти модифицированные потомки для работы еще и каких-то private-данных требуют, то начинается протяжка параметров через всю иерархию...
Протяжка параметров это и хорошо и плохо. Хорошо тем, что делает связи явными (то есть при анализе кода можно понять данный параметр нужен только здесь или где-то еще). Плохо тем, что трудоемко. Правда, если параметр упакован в контракт данных, а контракт уже протянут, то может быть и не так трудоемко.
В целом MVC подход дает еще одну вещь - возможность использовать M без остальных частей. Например, у каждого сервиса построенного с помощью SysOperation теперь есть API - то есть если надо его встроить в свой процесс, можно взять и вызвать метод, заполнив контракт, а не вытягивать наружу параметры модифицируя существующий класс