Наследование - зло

спасибо

а как это аргументировать другим? )

я сама против него, но интересно мнение опытных людей

Наследование создаёт ненужное сцепление (coupling). Если другие знают что это такое.
В результате изменение частей усложняется, потому что затрагиваются зависимые компоненты.

Есть принципы KISS и бритвы Оккама. Делать просто, и если можно достигать того же самого с наследованием и без, то наследование лишнее - а значит его режем.

Эти кейсы отлично решаются без наследования самыми базовыми функциями языка - класс, метод, поле.

Спасибо

По мимо Оккама, можно ещё сослаться на GOFов. Кажется это они высказали принцип - предпочитать композицию наследованию. Аргументируя это тем что при наследование наследуется много быть может не нужного. И это трудно контролировать. И вносить изменения в родителя трудно. А в композиции контроль доступа, замену и прочее легче обеспечить.
+ ещё аргумент - молоденький язык который разработала Google что бы он соответствовал современным реалиям тоже отказался от наследования в пользу композиции. Язык Golang.

Алексей, но ведь наследование всегда можно обойти, пусть и посредством дублирования кода и перегрузкой, так может и не нужно оно, наследование то?

привет . селениде и Prometheus как то могут взаимодействовать?

о спасибо - посмотрю . для меня это очень важно)

еще вопрос - на гитхабе есть примеры и ехампле , где поднимаются тесты сначало в хромБраузере, затем в мозиле?

Это решается сменой 1 значения, какие вам примеры нужны? Configuration.browser = "firefox";

не работает

ищу рабочий пример

Подскажите на сколько подход хорош хранить проверки в отдельном классе? И на сколько чейны в тесте норм?  вот пример теста

public void check1() {
    new Form()
            .selectItem1(ITEM_1)
            .selectItem2(ITEM_2)
            .setValue"200");
    new Asserts()
            .elementShouldNotBeVisible("item1")
            .elementShouldNotBeVisible("item2");
}

может я что то перемудрил и есть KISSee варианты )))