Другой возможностью было бы назвать его Proxy . Decorator и Proxy технически очень похожи - в большинстве случаев разница не техническая, а основанная на намерении.Ваш пример немного минимален, и поэтому трудно угадать намерение.
Редактировать
На детальном уровне: Screen
и SubScreen
doне делиться кодом.Если вы начнете добавлять методы к обеим реализациям и общему интерфейсу AddComponents
, вы можете обнаружить
- , что вам необходимо продублировать код как в
Screen
, так и в SubScreen
(или делегировать Screen
) и - что вы должны добавить методы к
AddComponents
, которые делают этот интерфейс плохо названным.
Если оба класса экрана похожи, оба на абстрактном логическом уровне и на уровне реализации тогда класс AbstractScreen
с двумя производными классами будет лучше.Чтобы вернуть образец речи: используйте Factory Method в AbstractScreen
, чтобы специализировать поведение различных кнопок.
В вашем текущем коде есть одна странная вещь: почему существует методaddButton
определены в любом случае?Просто добавьте кнопки в соответствующий конструктор, так как в любом случае пользователь должен вызвать addButtons
, а у метода нет аргументов.
Еще один не объясненный момент заключается в следующем: SubScreen
имеет ссылку на Screen
который не используется.Зачем?Будет ли больше методов во всех участвующих классах Screen
, SubScreen
и AddComponents
?Будет ли каждый метод иметь SubScreen
делегат для Screen
или только половину из них?
Видите ли, есть много возможностей, которые мы не знаем и не показаны в примере кода, но очень важны.Я уверен, что ваша голова содержит много деталей, говорящих: «Этот предложенный материал не будет работать, потому что я хочу сделать то или иное, так или иначе, в ближайшем будущем».К сожалению, мы не можем получить содержание вашей головы на этом сайте без дополнительной записи.: -)