ООП дизайн это вообще интересная и сложная тема. Нет серебряной пули. "Мы использовали ПО, а получилась сложная жуть ничем не лучше, как же так".
Помимо "основного" ПО есть и другие паттерны (Алименков неплохо начинал доклад, есть и другие материалы похожие) .
НО. ООП-дизайн это "разложить методы по коробочкам так чтобы их было удобно доставать". Это не "один размер для всех", и не "один пейджобджект всем".
Бывают ситуации когда на всех страницах меню — и оно делается отдельным объектом. Бывают разбиения сложных менюшек на несколько объектов.
Бывают ПО с флюэнтом и без.
Бывают ситуации когда ПО только усложнит (Солнцев, доклад "10 причин моей ненависти"),
бывают ситуации когда локаторы лучше хранить отдельно и загружать из отдельных файлов (для прогона на похожих-но-разных продуктах), бывают ситуации когда на это можно не заморачиваться и локаторы класть прямо в ПО.
Из-за такого разнообразия возможных ситуаций и "боков" я полагаю неправильным давать только один материал по ПО и ООП. Надо брать несколько материалов и смотреть с разных сторон. ПО это часть процессса, и даже не его краегугольный камень.
Материалы (находятся на Ютубе):
Концептуальные основы ООП на пальцах в контексте QA | Антон Семенченко на QA Z-DAY
https://www.youtube.com/watch?v=Nnlry9rl_usДесять причин моей ненависти - Андрей Солнцев
https://www.youtube.com/watch?v=pln38fIbYqAhttps://www.youtube.com/watch?v=EnooA2kEhY0Николай Алименков — Паттерны проектирования в автоматизации тестирования
Антипаттерны UI-Автоматизации. Антон Семенченко.
https://www.youtube.com/watch?v=EnooA2kEhY010 популярных способов превратить простое в сложное при Автоматизации тестирования
https://www.youtube.com/watch?v=stipcacBp_4Дмитрий Буздин — Как построить свой фреймворк для автотестов?
https://www.youtube.com/watch?v=vrjN8VTeuOkРазработка фреймворка для старта UI Автоматизации на примере Selenium. Антон Семенченко
https://www.youtube.com/watch?v=4K-eMpQ4XrY__________
Материалов много, я понимаю — но несмотря на то что изначальная тема "просто пейджобджект", у неё нет однозначного решения, решение зависит от контекста, где-то пейджобджект может быть вообще не нужен, а где-то он типичная строительная конструкция фреймворка, но надо понимать что типичная строительная и место конструкции.
Ну и, поскольку пейдобджект это обджект и часть ООП, стоит понимать не только формальные принципы ООП, а зачем человеческим оно, какая система автоматизации нам нужна и почему.