public abstract class CollectionCondition extends AbstractCondition<List<WebElement>> {
}
/*
    отсюда ушел весь код)
    в принципе - мы используем этот тип - как предка для кондишенов

    мы - объявляя кондишены - используем
        public class ListNthElementHasText extends CollectionCondition
    а не
        public class ListNthElementHasText extends AbstractCondition<List<WebElement>>

    что немного проще - и ради этого - можно оставить  этот класс
    а можно - убрать эту ступень в иерархии

    касается и ElementCondition
*/
************************************************
public interface LazyElement extends LazyEntity <WebElement>, WebElement {


    public void click();
    public void clear();
/*
    такие методы есть и у WebElement )
    потому - эти тут убирай
    нету смысла тут объявлять одноименные методы с методами интерфейса-предка
    потому - непонятно - какой интерфейс будет источником объявлений для метода
    как бы - нам оно не мешает, но может запутать
    а главное - нету в этом полезного)

    а вот doubleClick(), hover(), setValue(...) - нету )
    эти тут стоит объявить
    и реализовать в AbstractLazyElement
*/
*******************************
    @Override
    public String getTagName() {
        waitFor(this).until(present());
        /*
            подождали правильно
        */
        getWrappedEntity().getTagName();
        /*
            получили имя тега
            но - полученое значение никак не использовали
        */
        return String.valueOf(this);
        /*
            а вместо имени тега - вернули тестовое предстваление нашего объекта

            у нас просили имя тега)
        */
    }
**************************************
       @Override
        public String getAttribute(String s) {
            waitFor(this).until(present());
            getWrappedEntity().getAttribute(s);
            return String.valueOf(this);
        }
/*
    тут - аналогичная проблемка)

    получили значение атрибута, но вернули другое)

    и я бы подправила имя параметра
    я в курсе - что это еще на уровне объявления WebElement проблемка
    но тут - мы в состоянии имя параметра сделать нагляднее
    name -  будет в самый раз)
*/
**************************
    @Override
    public String getText() {
        waitFor(this).until(visible());
        getWrappedEntity().getText();
        return String.valueOf(this);
    }
/*
    тут тоже - получили текст
    но его не вернули
*/
*********************************
    @Override
    public List<WebElement> findElements(By by) {
        waitFor(this).until(visible());
        getWrappedEntity().findElements(by);
        /*
            вот findElements - уже возвратил - то что нам нужно
            это и нам надо вернуть
        */
        return (List<WebElement>) this;
    }
*********************************
    @Override
    public WebElement findElement(By by) {
        waitFor(this).until(visible());
        getWrappedEntity().findElement(by);
        /*
            верни результат getWrappedEntity().findElement(by);
        */
        return this;
    }
*****************************************
    @Override
    public String getCssValue(String s) {
    /*
        тут тоже имя параметра можно улучшить до propertyName
        к примеру
        или просто name
    */
        waitFor(this).until(visible());
        getWrappedEntity().getCssValue(s);
        /*
            то же самое - возвращай результат getWrappedEntity().getCssValue(s);

            как-то через один метод - ок
            а через один - с такой проблеммой)

            тут кстати лучше ждать present()
            для таких вещей видимости  и не нужно
        */
        return String.valueOf(this);
    }
*************************************
    @Override
    public boolean isDisplayed() {
        waitFor(this).until(visible());
        /*
            тоже интересно)
            сначала - дождемся - что элемент видим

            а потом - ответим - видим он или нет)

            тут ждать present()
        */
        return getWrappedEntity().isDisplayed();
    }
****************************
http://joxi.ru/DmBNWL6FNRNzom
http://joxi.ru/823k1x0U6P6DV2

/*
    я бы интерфейсы вынесла на уровень выше

    мы же в итоге - будем оперировать именно итпами этих интерфейсов
    потому глубоко запихивать - такое не надо
    но и выносить из wrappers - не стоит
*/
****************************
public class LazyWrappedWebElement extends AbstractLazyElement
/*
    в этот класс я бы передавала не только вебэлемент
    но и родительскую сущность - откуда мы добыли этот вебэлемент

    чтоб потом в toString  вот такое писать
    "WebElement " + element.toString() + " from " + parentEntity;

    причем - мы моем это добыть как в коллекции, так и в элементе
    потому parentEntity - это именно LazyEntity
    к этому типу можно привести как коллекцию так и элемент
*/
***********************************
public interface LazyCollection extends LazyEntity<List<WebElement>>, Iterable<LazyElement> {

    ....

    public WebElement get(List <LazyElement> lazyElements, int index);
    /*
        в правильном месте объявила
        но - перемудрила )

        это - метод коллекции
        потому - не нужен параметр List <LazyElement> lazyElements
        т к мы оперируем именно элементами коллекции - того же объекта
        чей это метод

        и возвращает этот метод не WebElement
        а тоже LazyElement
    */
}
**********************************
 public WebElement get(List<LazyElement> lazyElementList, int index) {
     return new ElementOfLazyCollection(lazyElementList, index).getWrappedEntity();
 }

/*
    верно - мы создадим новый лейзи-элемент нового специального типа

    и передадим ему - лейзи-коллекцию (this)
    и индекс

    и вернет этот метод - собственно этот лейзи-элемент

    все лейзи-элементы - можно привести к типу LazyElement
    так что LazyElement - это тип
    который возвращает этот метод

    а по сути - это объект нового типа ElementOfLazyCollection

    про вот такое использование типа интерфейса - почитай
    http://stackoverflow.com/questions/1932247/abstract-classes-and-interfaces-best-practices-in-java
    http://joxi.ru/E2pdR1lFB1pyM2

    про this
    https://docs.oracle.com/javase/tutorial/java/javaOO/thiskey.html
    http://stackoverflow.com/questions/2411270/when-should-i-use-this-in-a-class


    а getWrappedEntity() - не
    нам тут не надо
    тут - мы лишь фиксируем - как искать то, что нам надо

    начнем искать - когда будет потребность
    или проверка, или работа с элементом
    и там уже - и подождем и получим getWrappedEntity()
*/
***********************************
 public Iterator<LazyElement> iterator() {
 /*
    с этим - все ок
 */
****************************************
public class ElementOfLazyCollection {
/*
    все классы - будем называть по схеме
    Lazy+откуда+уточнения+Element
    LazyCollectionNthElement - будет ок
*/

    List<LazyElement> lazyElementList;
    /*
        тут будет LazyCollection parentCollection

        в конструкторе - тоже
    */
    int index;
...

    public WebElement getWrappedEntity() {
        return lazyElementList.get(index);
        /*
            а тут уже воспозьзуемся getWrappedEntity() нашей родительской коллекции
            это - список вебэлементов
            и из нее - уже по индексу получишь что нужно
        */
    }
}
*****************************************
*
    ну и еще один наворот на тему интерфейсов )

    как выше писала - класс может имплементировать несколько интерфейсов

    и прикольно - всю функциональность описывать на уровне интерфейсов
    это дает ряд интересных полезных эффектов

    вот тут например -
    описать интерфейс DescribesResult
    с методами expected() и  actual()

    и пусть класс AbstractCondition<V> имплементирует как Condition<V>, так и DescribesResult

    первая мелочь - можно описания абстрактных методов отсюда убрать
    (они же и так объявлены в интерфейсе, а реализовывать мы будем в кондишенах уже)

    вторая приятная и важная вещь - соблюли лучше Single Responsibility Principle

    третья приятная вещь
    конечно, при условии, если таки для переменных-кондишенов будем использовать типы интерфейсов
    CollectionCondition & ElementCondition (выше описаннный вариант 1)
    когда мы будем оперировать переменной
        CollectionCondition condition
        или
        ElementCondition condition

    то для такой переменной - мы не сможем вызвать методы  expected() /   actual()
    т е - там, где это было нужно - у нас эта функциональность была видна
    а там, где это не нужно - этого вообще не видно

    аналогично - для LazyEntity
    можно для порядку вынести объявление метода identity
    в интерфейс DescribesEntity
    и от него отнаследовать LazyEntity
*/