http://joxi.ru/MAj1YoWsvz8gJ2

/*
    в именах пекеджей - все буквы должны быть маленькими
    в прошлый раз писала - как это полечить
*/
***************************************
public interface AbstractElement<V> {
    V getWrappedEntity();
    By getLocator();

}
/*
    для интерфейса - в имени - не нужно применять Abstract
    это будет - для абстрактного класса

    пока рано говорить - что это - элемент или коллекция
    это - сущность, причем ленивая )
    LazyEntity - будет ок

    метода getLocator() - не нужно
    мі обойдемся без него

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

    дельно по неймингу
    http://www.vertigrated.com/blog/2011/02/interface-and-class-naming-anti-patterns-java-naming-convention-tautologies/

    еще на эту же тему
    http://stackoverflow.com/questions/2814805/java-interfaces-implementation-naming-convention
    https://web.archive.org/web/20130331071928/http://isagoksu.com/2009/development/java/naming-the-java-implementation-classes
    http://programmers.stackexchange.com/questions/152759/should-i-add-an-abstract-prefix-to-my-abstract-classes
*/
*******************************
public interface Condition<V> {
    V apply(LazyEntity<V> element);
}
/*
    тут все ок

    за исключением имени параметра
    точнее будет  - не element, а lazyEntity
    т к мы пока не знаем - что это - элемент или коллекция
*/
****************************
public abstract class AbstractCondition<V> implements Condition<V>{

    private By locator;

    public V apply(LazyEntity<V> element) {
        this.locator = element.getLocator();
        /*
            ним не нужно тут локатором оперировать
            убирай и поле, и его заполнение

            в toString() кондишена - оперировать будем не предствалением локатора
            а строковым представлением нашей лейзи-сущности (а значит - и у лейзи-элемента, и у лейзи-коллекции - должен быть
            реализован метод toString - вот там как раз будет уместно выводить локатор как результат)

            во-первых - как ты ранее сохраняла значение локатора в поле - так теперь сохраняй
            лейзи-сущность.

            и тут имя параметру LazyEntity<V> element подправь

        */
***************************************


public <V> V until(Condition<LazyEntity<V>> condition, long timeout){
/*
    у нас кондишены - Condition<WebElement> & Condition<List<WebElement>>
    и это было ок, и по-прежнему ок
    мы уже получили лейзи-сущность  и проверим в ждущей проверке - кондишены - Condition<WebElement> или Condition<List<WebElement>>

    меняем тип у Condition<LazyEntity<V>> condition на Condition<V>
*/
*************
V apply = condition.apply(element);
/*
    вот тут теперь есть вопросы)

    можно конечно - грубо - привести результат к типу V
    V apply = (V) condition.apply(element);
    есть такой вариант - alt + enter
    похоже - вот в этом моменте я тебя в слеке куда-то не дуда завела)
    сорри)
    код уже не самый простой, проще его видеть живьем, а не в картинках

    так придется делать - т к тип в <...> не задан для  private LazyEntity element;
    и тут надо бы переименовать этот параметр на lazyEntity

    и для второго метода until - тоже подправь тип параметра

    если делать не грубо - то нужно дженерик-тип искользовать на уровне класса WaitFor
    а не как сейчас - на уровне метода until

    можно пока оставить грубое приведение типа)
    оставь на закуску этот момент

    когда по этому ревью будет все проработано - можно будет вернуться опять к этому моменту
*/
******************************
public class LazyElement implements LazyEntity<WebElement> {

    /*
        все реализованное - ок

        не хватает toString()
        в данном случае  - locator.toString() - будет оптимально


        метод getLocator() - и отсюда убирай
    */


    public void click(){
    /*
        уже сейчас с этим методом - проблем не будет - решили вопросы с типами в WaitFor

        вызывай вариант until - без таймаута уже
        вызов будет лаконичнее
    */
***********************************
public class LazyElements implements LazyEntity<List<WebElement>> {
/*
    чтобы сразу бросалась в глаза разница - элемент или коллекция
    предлагаю этот класс назвать LazyCollection
*/
   ...

    public static List<WebElement> $$(By locator) {
    /*
        это - метод для ConciseAPI
        тут он не нужен

        метод будет аналогичный методу $(By locator)
    */

    public By getLocator() {
    /*
        и этот метод - не нужен
    */
/*
    еще не хватает toString()
    и тут - locator.toString() - будет оптимально
*/
********************************
public static <V> V assertThat(By locator, Condition<LazyEntity<V>> condition) {
public static <V> V assertThat(By locator, Condition<LazyEntity<V>> condition, long timeout) {
/*
    эти методы уже не нужны

    нам для коллекции и для элемента - нужны методы should

    для элемента - should(Condition<WebElement> condition)
    или даже should(Condition<WebElement>... conditions)

    а для коллекции - should(Condition<List<WebElement>>... conditions)


    дальше смотрим)

    метод $ - возвращает значение LazyEntity<WebElement>
    значит - когда мы получим это значение - мы сможем вызвать лишь методы интерфейса LazyEntity

    для коллекции и элемента - у нас разные наборы методов
    отнаследуем от LazyEntity - 2 новых интерфейса - для элемента и коллекции
    и уже в этих интерфейсах - объявляй все методы, которые нужны уже - для элемента и коллекции - соответственно

    пройдись по gmail-задаче
    что нужно для работы с коллекцией и элементами - реализуй

    с todoMVC - не торопись пока

    по идее - уже с этими изменинями gmail-задача будет работоспособной
*/