Цитата:
|
Соглашусь. Но это единственный профит. Тем более он никак не противоречит добавлению прозрачного (ну или не совсем прозрачного) спрайта под модальное окно.
|
Если правильно разруливать – тогда шейпа. Затемнение всегда окей )
Цитата:
Engine.gameStage.stage.addChild(this) лежит в конструкторе this
и на фига метод?
|
Инкапсулировать такую жуть
Если такая запись у Вас не вызывает зрительного отторжения – ну что же, у всех своё чувство прекрасного.
Но вот из минусов:
1) Это DRY до тех пор, пока все модальные окна наследуются только от этого, у которого в конструкторе написано то-самое.
2) Это рушит парадигму обязанностей у объектов на уровне того, с чем работаем. Поясню: если есть некоторый ModalManager, который может добавлять IModal – то вся работа заканчивается на реализации интерфейса IModal. Какие кривости использует ModalManager – никого не волнует. А вот "вшивая" его в цепочку наследования – приходится ориентироваться на родительский класс, потому что это не какой-то там IModal, который никому плохо не сделает. Можно говорить о том, что AbstractModalWindow – тоже "пофиг" как работает, мол, работаем же со спрайтом "в черную", но вам же
приходится ориентироваться при разработке на него.
3) Если требуется метод очищения всех модальных окон (предположим, их может быть стек) – вообще непонятно, чья обязанность.
4) Для стороннего разработчика – если всеми правдами-неправдами можно подогнать это под single responsobility – то под KISS – никогда.
5) А как насчет модальности не для stage?
6) Реиспользуемость кода – отсутствует. Прямая связанность с каким-то Engine.
7) Для каждого показа модальное окно нужно пересоздавать.