public class WaitFor {
    ...
    private By locator;
/*
    тут - уже не нужен локатор

    как и комментарии)

    предлагаю почистить и реформатировать

    а также - метод sleep
    сместить вниз  - чтобы от гравного не отвлекаться
*/
*********************
public static WebElement setValue(WebElement element, String text) {
public static void doubleClick(WebElement element) {
public static void hover(WebElement element) {
/*
    нам такие методы в ConciseAPI не нужны

    они будут полезны - как методы для LazyElement
*/
**************************************
T t = (T) condition.apply(entity);
/*
    такого плана имена переменных мы уже обсуждали)

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

    остальное - требует осмысленных имен
*/
********************
src / main / java / ui / net / itlabs / core / LazyEntity.java

перемести интерфейс в пекедж src / main / java / ui / net / itlabs / core / entities /
к своим ближайшим родственникам)
*****************************
public class Present extends ElementCondition {
    Boolean isPresent = false;

 ...
    @Override
    protected boolean check(WebElement element) {
        if (element != null) {
            isPresent = true;
        }
    /*
        тут тоже все проше
        isPresent = (element != null);
    */
******************************

    public LazyElement shouldBe(Condition<WebElement>... conditions) {
        return should();
    }

    public LazyElement shouldHave(Condition<WebElement>... conditions) {
        return should();
    }
    .................

    public LazyCollection shouldBe(Condition<List<WebElement>>... conditions)  {
        return should();
    }

    public LazyCollection shouldHave(Condition<List<WebElement>>... conditions)  {
        return should();
    }
/*
    а параметры передать при вызове should(????)

    касается и LazyCollection и LazyElement
*/
****************************************
public class LazyElement implements LazyEntity<WebElement> {

   ...
    private WebElement element;
/*
    это поле уже не используется
    убивай
*/
***********************************************************************

Классов lazy - семейства - у нас будет несколько

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

getDriver.findElement(...) / getDriver().findElements(...)

это и отразим в имени классов
LazyWebDriverElement
LazyWebDriverCollection


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

    следующий наворот )

    Это в java-ООП мире достаточно прикольная практика -
        всегда, когда ты хочешь сделать какие-то штуки внутри объекта публичными -
        выносить их сначала в отдельный интерфейс - и потом его имплементировать

        потому что просто сделать какие-то штуки публичными - это недостаточно "строго"

        если ты четко заявляешь - мой объект поддерживает такие-то интерфейсы, тогда
        все могут общаться с твоим объектом через четко прописанное API этого интерфейса

    реализуй интерфейсы
     LazyCollection отнаследовав от LazyEntity<List<WebElement>>
     LazyElement отнаследовав от LazyEntity<WebElement>

    в этих интерфейсах - объяви те public-методы
    которые уже реализованы в классах LazyWebDriverElement и LazyWebDriverCollection

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

    но - и это еще не все)

    как я и говорила - у нас будут разные лейзи-элементы и разные лейзи-коллекции
    например
            lazyElement.find(".destroy")
            lazyCollection.find(cssClass("edited"))
            lazyCollection.get(3)
        т е - в итоге - у нас будет несколько классов, имплементирующих interface LazyElement
        причем - отличаться у них будут лишь конструкторы и  реазицация getWrappedEntity
        а реализация остальных методов, да и вообще набор методов - один-в-один

    И во всех этих случаях - нам нужно, чтобы у лейзи-элементов - были методы should, click ...
    т е - все - что мы уже реализовали в LazyWebDriverElement
    (почти все - все же реализация конструктора, getWrappedEntity, toString - будет у разных классов своей)

    Вот мы для лейзи-элементов - реализуем абстрактного предка AbstractLazyElement
    в этом классе будут реализованы почти все методы, что мы реализовали ранее в LazyWebDriverElement
    все - что будет общим для всех лейзи-элементов

    И уже от AbstractLazyElement будем наследовать наш LazyWebDriverElement
    в котором и реализуем только то, что его отличает от его абстрактного предка -
    конструктор, getWrappedEntity, toString

    Аналогично - поработай и с лейзи коллекцией
    Организуй и тут абстрактного предка
    и вынеси в него все общее

    а в LazyWebDriverCollection - останется лишь то, что отличает его от абстрактного предка -
    конструктор, getWrappedEntity, toString

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

/*

    вот и получим такую иерархию

     самый общий интерфейс
     LazyEntity<T>

        его потомки - интерфейсы
            LazyElement
            LazyCollection

            абстрактные классы
                AbstractLazyElement
                AbstractLazyCollection
                (реализуем все методы, кроме абстрактного getWrappedEntity,
                 также конструктор нам тут не нужен - т к класс абстрактный,
                 и toString - реализовівать будем в потомках)

                    набор классов - для элементов и коллекций
                        наши уже разработанные варианты
                            LazyWebDriverElement
                            LazyWebDriverCollection

                        список будет пополняться)

     получишь что-то такое http://joxi.ru/GrqLOX3SNZPLoA
     пока закрасила те классы - которые еще у нас не появилимь)
     ну и разумно - это в рамках core - выделить в отдельный пекедж
     wrappers (или entities) - хорошее общее название
     т к вот эти наши классы - это лишь обертка вокруг вебэлемента/списка вебэлементов

     есть конвеншенсы и по этому поводу - какие имена давать интерфейсу, какие - абстракному предку,
     какие - классам-потомкам

     статья про это (лучший вариант)
        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

     Interfaces, abstract classes - good practice
         http://stackoverflow.com/questions/1932247/abstract-classes-and-interfaces-best-practices-in-java
         http://joxi.ru/E2pdR1lFB1pyM2
*/
************************************************************

/*
    теперь - поправь методы $ & $$
    внутри метода - создаем объект конкретного типа (LazyWebDriverElement / LazyWebDriverCollection)
    и его вовзращаем

    а тип возвращаемого резултьтата - это соотвествующий интерфейс (LazyElement / LazyCollection)

    просмотри код - вне наших лейзи-сущностей - мы оперируем интерфейсами
    Мы не заводим переменную типа LazyWebDriverElement
    а используем тип LazyElement


    в пейджах, например просмотри)

*/
*******************************************************
/*
    И еще один наворот

    WebElement - это тоже интерфейс

    мы можем создать интерфейс, который является наследником нескольких интерфейсов

    Если мы отнаследуем наш интерфейс LazyElement от WebElement
    (в том числе, наследование от LazyEntity - никуда не убираем)
    то - это то же самое что и заявить -
    "наш LazyElement - полная замена WebElement - и везде где вы его использовали
    вы теперь можете использовать наш лейзи враппер
    который помимо всех фич вебэлемента еще и будет ждать себя..."

    конечно, можно было бы абстрактный класс реализовать имплементирующим два интерфейса
    Класс может быть реализован с имплементацией нескольких интерфейсов

    но тогда, при использовании переменной типа LazyElement - мы не получим функциональности WebElement

    потому тут правильнее именно отнаследовать LazyElement от WebElement

    тут надо внимательно к вопросу подойти)

    в рамках интерфейса LazyElement - не объявляй методов, одноименных с методами интерфейса WebElement
    так, останется в LazyElement - совсем немного методов

    да, мы для некоторых методов потерям chainable возможности

    но зато не будет двусмысленностей

    в абстрактном классе AbstractLazyElement - реализуй все вебэлементовские методы
    думаю, проблем с этим не будет

    думай - в каких методах и чего надо ждать - ничего не ждать / ждать видимости / ждать наличия в DOM

*/