Статическое событие. Костыль или нет

@ASDFD12 · Регистрация: 15.09.2012

Студворк — интернет-сервис помощи студентам

Суть следующая. Приложение на андроид.
В нем динамически создаются диалоговые окна (класс диалоговых окон Dialog).
В классе Dialog есть статический метод Create , который собственно и создает окна разных типов.
Есть обьект класса Control, который должен по нажатии клавиши back на телефоне закрывать диалог - если он существует.
Control не синглтон, также динамически создается в определенные моменты.
Суть в том - пока он создан - должен выполнять свои действия (обработку клавиши Back)

Что сделал:
Сделал статический event OnCreate и вызываю его в в статическом методе Create класса Dialog

C#
1
2
3
4
5
6
7
8
9
10
public event System.Action<Dialog> OnCreate;
 
public static Dialog Create()
{
Dialog dialog = InstantiateDialog();
if(OnCreate != null){
OnCreate(dialog);
return dialog;
}
}

В класе Control, в момент создание подписываемсь на событие

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class Control
{
private Dialog  _context;
public Control()
{
Dialog.OnCreate += HandlerOnCreate;
}
public void  HandlerOnCreate(Dialog dialog)
{
_context = dialog;
Dialog.OnCreate -= HandlerOnCreate;
}
 
void Update()
{
if (!pressBack){
return;
}
if(_context != null){
_context.HideDialog();
_context = null;
} else{
QuitProgramm();
}
 
}
 
}

Одновременно может быть открыт только один диалог, если не открыт - нажатие вызывает закрытие программы.
Достоинством способа считаю минимальная связность класса Control c Dialog. Легко можно адаптировать под закрытие нескольких окон, сделать стек контекстов и закрывать по порядку).
Костыльный ли способ? Как по поводу утечки памяти?

@aquaMakc · 24.02.2015, 13:56

) это очень сложный вопрос для этого форума
Собственно зачем делать статический метод и событие? Пусть у каждого экземпляра класса диалог будет свой метод закрытия.
Как я понял один диалог - это одна форма с одним контролом закрытия. Не вижу смысла усложнять логику статическим общим методом закрытия.

@ASDFD12 · 24.02.2015, 14:06 **[ТС]**

Сообщение от aquaMakc

Как я понял один диалог - это одна форма с одним контролом закрытия

не совсем так. Есть централизированый компонент Control, который выполняет закрытие активного окна, если окна нет вызывает диалог выхода с приложения, тоесть екземпляр Control не входит в состав диалога.
Смысл в том что диалог может появится в любой момент и про существования екземпляра Control ничего не должен знать. Тоесть если есть екземпляра Control - он обработает нажатие кнопки бек и закрыет диалог, если нет - ничего не сработает.

@aquaMakc · 24.02.2015, 14:12

Ага. Т.е. контрол - это отдельный объект, тоже неплохо. Не совсем понятно только почему он может быть не создан.
Лично я вижу такую структуру:
Есть какой-то класс программы, пусть он будет коренным;
Есть класс Диалог, есть класс контрол (кнопка);
В коренном классе последовательно создаются экземпляры класса диалог, при этом они заносятся в стек типа диалог;
По клику контрола происходит извлечение элемента стека и выполнение метода закрытия;
Если стек пустой - закрывается программа.

В этой схеме я не вижу необходимости статических методов и событий.

@ASDFD12 · 24.02.2015, 14:18 **[ТС]**

это сделано для движка Unity3d, там есть понятие сцен, когда мы переходим из сцены в другую - все обьекты текущей сцены удаляются (можно конечно сделать Control компонент и неудаляемым , но это не меняет сути вопроса). Можно конечно при каждом создании диалога искать компонент Control и передавать туда диалог + проверка есть ли Control компонент. Но чем этот вариант будет лучше?

@aquaMakc · 24.02.2015, 14:48

Я мало знаком с особенностями программирования под андроид в юнити, но мне кажется, ты пошёл по неправильному пути.
Как я понимаю, диалоговые формы (сцены) создаёшь ты. То, что там будет отображаться задаётся параметрами? Создание происходит по какому-нибудь событию? Закрытие происходит по отлавливанию события нажатия кнопки "back"?
Я бы сделал так:
В классе диалог создал бы метод закрытия и формирования экранной формы.
При необходимости создания формы создавал класс диалог. При этом создавал бы экранную форму.
При создании новой сцены, текущий диалог заносится в стек. После чего текущая сцена заменяется новой.
При отлавливании события "back" происходит закрытие текущего диалога, выборка из стека предыдущего и формирование формы.

Добавлено через 1 минуту
Естественно всё это делается в основном классе программы.

Добавлено через 6 минут
И в конце, если по событию "back" стек пуст - закрываем программу.

@ASDFD12 · 24.02.2015, 14:50 **[ТС]**

Я так понял ты предлагаешь в основном классе программы создать стек диалогов и туда их помещать при создании. А при нажатии кнопки бек, класс Контрол будет обращаться к этому стеку и подчищать его. Так?

@aquaMakc · 24.02.2015, 14:58

да. также я предлагаю инкапсулировать методы создания и удаления внутри класса диалог. Ибо внешний класс закрытия окна - это даже не костыль, это целый антипаттерн.

@ASDFD12 · 24.02.2015, 15:14 **[ТС]**

Я понял. Не все так плохо. В класе диалог есть методы закрытие, открытие, установка текста сообщения. На диалогах есть кнопка закрытия при нажатии которой срабатывает метод диалога по закрытию ( все это инкапсулировано). При нажатии кнопки бек

C#
1
2
3
4
5
6
7
8
9
10
11
void Update()
{
if (!pressBack){
return;
}
if(_context != null){
_context.HideDialog();
_context = null;
} else{
QuitProgramm();
}

Просто основной фишкой считал минимальная связность обьектов. У меня ее по сути нет.
В твоем случае получается класс контрол должен существовать в контексте главного класса или должен быть метод получения этого класса (это одна связность). Также в главном классе нужен методы по работе со стеком и это все как то будет запутывать логику основного класса. Это мне так кажется) Хотелось бы услышать плюсы минусы обох вариантов?

@aquaMakc · 24.02.2015, 15:21

в моём случае класс контрол вообще не нужен, созданием и удалением занимается основной класс программы

Добавлено через 1 минуту
Если у тебя программа сложная, а диалоги намного более функциональны, чем просто отображение пары строк текста, то есть смысл создания класса-диспетчера, который будет отвечать за стек, создание и удаление. Но я сомневаюсь, что у тебя настолько сложный продукт.

@ASDFD12 · 24.02.2015, 15:21 **[ТС]**

делал отдельный класс для разнесения логики, думаю это правильно

@aquaMakc · 24.02.2015, 15:24

разнесение логики - это правильно, но нельзя доводить до абсурда. Создание статического отдельного класса, имеющего только одну функцию - закрытие окошка - это и есть доведение до абсурда.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 13:56
	) это очень сложный вопрос для этого форума Собственно зачем делать статический метод и событие? Пусть у каждого экземпляра класса диалог будет свой метод закрытия. Как я понял один диалог - это одна форма с одним контролом закрытия. Не вижу смысла усложнять логику статическим общим методом закрытия. 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 14:12
	Ага. Т.е. контрол - это отдельный объект, тоже неплохо. Не совсем понятно только почему он может быть не создан. Лично я вижу такую структуру: Есть какой-то класс программы, пусть он будет коренным; Есть класс Диалог, есть класс контрол (кнопка); В коренном классе последовательно создаются экземпляры класса диалог, при этом они заносятся в стек типа диалог; По клику контрола происходит извлечение элемента стека и выполнение метода закрытия; Если стек пустой - закрывается программа. В этой схеме я не вижу необходимости статических методов и событий. 0

@ASDFD12 58 / 57 / 15 Регистрация: 15.09.2012 Сообщений: 557
	24.02.2015, 14:18 [ТС]
	это сделано для движка Unity3d, там есть понятие сцен, когда мы переходим из сцены в другую - все обьекты текущей сцены удаляются (можно конечно сделать Control компонент и неудаляемым , но это не меняет сути вопроса). Можно конечно при каждом создании диалога искать компонент Control и передавать туда диалог + проверка есть ли Control компонент. Но чем этот вариант будет лучше? 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 14:48
	Я мало знаком с особенностями программирования под андроид в юнити, но мне кажется, ты пошёл по неправильному пути. Как я понимаю, диалоговые формы (сцены) создаёшь ты. То, что там будет отображаться задаётся параметрами? Создание происходит по какому-нибудь событию? Закрытие происходит по отлавливанию события нажатия кнопки "back"? Я бы сделал так: В классе диалог создал бы метод закрытия и формирования экранной формы. При необходимости создания формы создавал класс диалог. При этом создавал бы экранную форму. При создании новой сцены, текущий диалог заносится в стек. После чего текущая сцена заменяется новой. При отлавливании события "back" происходит закрытие текущего диалога, выборка из стека предыдущего и формирование формы. Добавлено через 1 минуту Естественно всё это делается в основном классе программы. Добавлено через 6 минут И в конце, если по событию "back" стек пуст - закрываем программу. 0

@ASDFD12 58 / 57 / 15 Регистрация: 15.09.2012 Сообщений: 557
	24.02.2015, 14:50 [ТС]
	Я так понял ты предлагаешь в основном классе программы создать стек диалогов и туда их помещать при создании. А при нажатии кнопки бек, класс Контрол будет обращаться к этому стеку и подчищать его. Так? 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 14:58
	да. также я предлагаю инкапсулировать методы создания и удаления внутри класса диалог. Ибо внешний класс закрытия окна - это даже не костыль, это целый антипаттерн. 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 15:21
	в моём случае класс контрол вообще не нужен, созданием и удалением занимается основной класс программы Добавлено через 1 минуту Если у тебя программа сложная, а диалоги намного более функциональны, чем просто отображение пары строк текста, то есть смысл создания класса-диспетчера, который будет отвечать за стек, создание и удаление. Но я сомневаюсь, что у тебя настолько сложный продукт. 0

@ASDFD12 58 / 57 / 15 Регистрация: 15.09.2012 Сообщений: 557
	24.02.2015, 15:21 [ТС]
	делал отдельный класс для разнесения логики, думаю это правильно 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	24.02.2015, 15:24
	разнесение логики - это правильно, но нельзя доводить до абсурда. Создание статического отдельного класса, имеющего только одну функцию - закрытие окошка - это и есть доведение до абсурда. 1

Опции темы