SM
Если в классе есть какой-то метод или атрибут и ты не можешь ним воспользоваться не является ли это примером не правильной архитектуры ?
почему “не можешь”? оно “висит и не особо мешает” же
Size: a a a
2020 August 12
AV
Всем привет! Стоит ли выносить элемент в BasePage, если он есть на 5-ти страницах из 6
не стоит вообще делать basepage
B
не стоит вообще делать basepage
А что взамен?
AV
Опишу ситуацию: есть флоу заполнения формы из пяти шагов, каждый в виде отдельной страницы, на первом шаге есть кнопка 'Next', со второго по четвёртый есть кнопки 'Previous', 'Next' и 'Save', на пятом нету ничего. Вопрос: как в плане структуры это будет организовано в проекте? Будут сущности Page для каждого шага, где-то отдельно будет сущность NavigationComponent, с описанием всех трех кнопок? Или для каждой кнопки отдельный класс или интерфейс?
например: будет 5 объектов для каждой страницы (ну или как минимум 5 - возможно имеет смысл разбивать объекты на более мелкие виджеты).
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
JD
Ого. Вы там на ассамблере пишите что ли?
Очень здоровая форма
AV
А что взамен?
Пива например купить свежего.
AV
Какую проблему решает basepage?
AB
например: будет 5 объектов для каждой страницы (ну или как минимум 5 - возможно имеет смысл разбивать объекты на более мелкие виджеты).
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
+1
JD
например: будет 5 объектов для каждой страницы (ну или как минимум 5 - возможно имеет смысл разбивать объекты на более мелкие виджеты).
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
С навигацией зависит от того, как оно запрограммировано. Если навигация отдельная компонента - логично сделать (один) объект для неё. Но часто кнопки только выглядят одинаково, но на самом деле каждая forward-back кнопка уникальна (или закопипащена). Тогда логично не пытаться изобрести наследование или композицию там, где их нет - а обрабатывать кнопки или как часть "шага" или отдельными виджетами.
Т.е. все три кнопки описать в одном классе? И создавать объект этого класса в классе каждой страницы? Не плохо, что на первом шаге только одна из этих трех кнопок есть?
JD
Какую проблему решает basepage?
Дублирования кода, нет?
O
В смысле в одном page классе описать элементы и методы для всего флоу? Ну думаю не меньше тысяч трех строк выйдет
Почему? Если там однотипные элементы, то не так много.
не ну естественно я же не знаю, что там за форма. предполагаю только
не ну естественно я же не знаю, что там за форма. предполагаю только
O
Какую проблему решает basepage?
Если приложение состоит из однотипных элементов, которые повторяются на многих страницах, почему нет
(но, конечно, зависит что понимать под basepage)
(но, конечно, зависит что понимать под basepage)
JD
Olga
Почему? Если там однотипные элементы, то не так много.
не ну естественно я же не знаю, что там за форма. предполагаю только
не ну естественно я же не знаю, что там за форма. предполагаю только
Ну вообще да, довольно однотипные по большей части, но некоторые содержат уникальные и довольно большие гриды со своей функциональностью
AV
Про похожие кнопки свежая байка из RL. Был на сайте типичный хедер. Ну сверху такая штука - с менюшками и инфой всякой. Конечно же написали для неё один объект. Какого же было удивление - когда внезапно оказалось, что там несколько хедеров, которые друг-друга подменяют но выглядят (в основном) одинаково. Всплыло так - внезапно на одной из страниц линк "Login" был написан с маленькой буквы "login". Тогда-то и всплыло, что хедеры в несколько исходниках симметрично используются.
O
А не байка ли это о том, "как не надо делать" приложения а не тесты )))
SM
Про похожие кнопки свежая байка из RL. Был на сайте типичный хедер. Ну сверху такая штука - с менюшками и инфой всякой. Конечно же написали для неё один объект. Какого же было удивление - когда внезапно оказалось, что там несколько хедеров, которые друг-друга подменяют но выглядят (в основном) одинаково. Всплыло так - внезапно на одной из страниц линк "Login" был написан с маленькой буквы "login". Тогда-то и всплыло, что хедеры в несколько исходниках симметрично используются.
Жизнь богаче фантазии, да. Но мне всё равно кажется, что это - скорее клинический случай
AV
Дублирования кода, нет?
дублирование кода - это не есть проблема, если у тебя две разные кнопки, которые выглядят одинаково, нормально иметь два разных класса. И особенно - наследование - это неверный паттерн для уменьшения дублирования.
O
так а кто говорит о разных кнопках, кот выглядят одинаково... на формах они, обычно, и есть одинаковые
AV
Olga
А не байка ли это о том, "как не надо делать" приложения а не тесты )))
всё так.
JD
дублирование кода - это не есть проблема, если у тебя две разные кнопки, которые выглядят одинаково, нормально иметь два разных класса. И особенно - наследование - это неверный паттерн для уменьшения дублирования.
А если они и ведут себя одинаково? В моем случае эти кнопки именно такие - сэйв шлёт такой же запрос на тот же эндпоинт, навигационных - то же самое