public abstract class AbstractCondition<V> implements Condition<V> {

/*
    осталось с прошлого раза

    В интерфейсе Condition - дженерик-тип ты обозначала как T
    что корректнее с точки зрения конвеншенсов

    тут - оно тоже уместнее было бы
*/
************************************

http://joxi.ru/ZrJX8Y3f1pznq2

/*
    тут тоже - большая и маленькая буквы
    надо привести в чувства
*/
**************************************
  public <T> T until(long timeOutInSeconds, Condition<T>... conditions) {
/*
    А зачем тебе заново алгоритм мостить?

    уже все реализовано в public <T> T until(Condition<T> condition, long timeOutInSeconds)
    тут - просто переиспользуй его

    цель такого метода - вызывать проверки последовательно, аж пока какая-то не упадет

    цитата из прошлого ревью - см на сигнатуру метода и пояснения
*/
   public <V> V until(Condition<V>... conditions)
    /*
        суть - по очереди для каждого из кондишенов вызываем наш until(Condition<V> condition)
        до тех пор, пока проверки проходят - двигаемся по набору переданных кондишенов
        как только ждущая проверка для кондишена не прошла - дальше не проверяем
    */
****************************

/*
    Можно убрать (или закомментить)
    в pom - кусок про параллелизацию

    а в BaseTest - вернуться к использованию BeforeClass & AfterClass

    все что нужно для параллелизации - в conciseAPI у нас есть
    при необходимости - все подключишь

    сейчас будет быстрее отлаживаться  - когда браузер открывается, все тесты отрабатывают и потом он закрывается
*/
******************************************************************************************************
******************************************************************************************************
public interface Locator<V> {
    V getWrappedEntity (String cssSelector);
}
/*
    этот интерфейс - начало нашей иерархии

    у нас будет иерархия лейзи-сущностей
    часть из них - будет лейзи элементами
    часть - лейзи коллекциями

    потому - назовем этот интерфейс LazyEntity

    насчет параметра для getWrappedEntity
    он - не нужен)
    метод getWrappedEntity() - расскажет о своей сущности
    у некоторых сущностей будет свойство - локатор
    но это уже - свойство объекта

    на уровне этого интерфейса - мы говорим - что каждая лейзи-сущность может нам вернуть свое представление
*/
**********************************
http://joxi.ru/DrlQ5oLh4POKOm
/*
    а тут - будут переделки)

    пекедж переименуй в entities
    там потом - будут пекеджи element & collection

    пока классов мало - можно ограничиться переименованием commands -> entities

    из всего надора классов - нам нужны варианты
    LazyElement
    LazyElements (предлагаю его переименовать в LazyCollection - чтоб разница между элементом и коллекцией была поярче)

    оба эти класса будут иметь поле By Locator
    и конструкторы этих классов - будут получать локатор

    и оба эти класса будут имплементировать интерфейс  LazyEntity
        для LazyElement - LazyEntity<WebElement>
        для LazyCollection - LazyEntity<List<WebElement>>

    соответственно - в обоих этих классах будет реализован метод
    getWrappedEntity()
    который по локатору будет возвращать
        элемент (для LazyElement)
        или список элементов (LazyCollection)

    и далее - ранее разработанный WaitFor - научи работать не с локатором, а с лейзи-сущностью
    можно использовать для значений типа LazyElement &  LazyCollection -
    тип -  LazyEntity
    т к оба эти класса имплементируют этот интерфейс

    соотвественно - из кондишенов - уйдет метод getWrappedEntity
    т к мы будем использовать в работе - такой метод от самой лейзи-сущности

    в методах лейзи-элемента
            сначала - ждем видимости
            потом - получаем вебэлемент =  getWrappedEntity()
            и уже у него - выполняем соотвествующее действие
*/