Оптимизация Framework или одинаковый функционал на некоторых страницах

общие вопросы
, ,
#21

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

public class Footer{
          public Karaoke save(){
return new Karaoke(driver);
}

public Movie save(){
return new Movie(driver);
}

public Serials save(){
return new Serials(driver);
}

Понимаю что это не правильно, как быть?

#22

Так просто не получится сделать, поскольку перегрузка методов не работает с разными возвращаемыми типами.

Вот тут тебе и пригодятся интерфейсы :slight_smile: И генерики (они же дженерики, generics)

#23

То есть если я правильно понял на каждый вид Footer я создаю свой интерфейс используя обобщения. А сам интерфейс буду реализовывать в классе описывающий страницу, так?

#24

Типа того. На самом деле надо пробовать реализовывать и смотреть что получается. Даже в этом случае не сразу получается сделать удобно. А уж не видя кода что-то правильно подсказать и вовсе сложно. Пробуй делать, использовать, улучшать

#25

Хорошо, как сделаю напишу пример как это выглядит. Но вот еще вопрос по теме только отвлеченно. Когда мы создаем абстрактный класс Page и помещаем в него некоторые элементы которые встречаются на всех страницах, то как быть с методом который встречается только о половины из всех страниц?

Например в моем случае это элементы (Combobox,Checkbox,TextField) они все реализованы в абстрактном методе Page. От него наследуются все страницы (главная страница, форма и попап). Но что делать с методом List2List, он не встречается на главной странице? Стоит ли его также реализовать в Page?

#26
  1. Во-первых, классы элементов страниц (TextBox, Combobox и т.д.) не стоит делать частью страницы, а вынести их в отдельные классы
  2. Во-вторых, иерархия классов PageObject должна описывать иерархию типов страниц UI приложения. То есть в абстрактном классе AbstractPage описать только тот функционал, который присущ всем 100% страниц. Потом смотреть какие ещё типы страниц вырисовываются и делать под них общий родительский класс, наследованный от AbstractPage. А наследники этого родительского класса будут реализовывать конкретные страницы.

Например, иерархия классов может быть такой:

- AbstractPage
-- PageWithFooter
---- Page1
---- Page2
-- PageWithoutFooter
---- Page3
---- Page4
-- PopUpPage
---- Popup1
---- Popup2
etc.

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

#27

А это будет нормальным в данном случае на каждый метод описывающий работу с типом элемента, создавать отдельный класс? (тема опять наверно из разряда god object)

#28

Тебе не надо создавать класс на каждый метод, работающий с типом элемента. Тебе надо создать класс на каждый тип элемента. Потом уже в страницах использовать экземпляры этих классов для работы с элементами.

P.S. задавай уже конкретные вопросы, с кусками кода, в отдельных темах. А-то на пальцах каждый по-разному воспринимает информацию