src/main/java/ua/net/itlabs/core/wrappers/element/

public class LazyElementAllInnerElementsByLocatorCollection extends AbstractLazyCollection {
/*
    это - коллекция
    значит - в пекедже src/main/java/ua/net/itlabs/core/wrappers/collection

    про имя класса

    откуда = Element
    уточняем = Inner
    что = Collection

    LazyElementInnerCollection - будет ок

    реализация - ок

    в toString() - вместо find лучше бы использовать findAll
*/
************************
    @Override
    public boolean is(ElementCondition condition) {
        try {
            if (condition.apply(this) != null) {
                return true;
            }

        }
        catch (WebDriverException | IndexOutOfBoundsException e) {}
        return false;
    }

/*
    мы уже вместо IndexOutOfBoundsException мы уде вызываем исключение-потомка WebDriverException

    потому - тут уже IndexOutOfBoundsException ловить не нужно

    попробуй применить condition.check вместо condition.apply
    на пару строк лаконичнее)
*/
***************************
public <V> V until(Condition<V> condition, long timeoutMs) {
  ...
            } catch (WebDriverException | IndexOutOfBoundsException e) {
  ...
  /*
    тут тоже уже можно не ловить IndexOutOfBoundsException
  */
******************************
 public interface Condition<T> {

     T apply(LazyEntity<T> entity);
     boolean check(T wrappedEntity);
 }

 /*
     делаем красиво)

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

     нарушаем Single Responsibility Principle )

     реализуй интерфейс Matcher <T> с объявленным методом boolean check(T wrappedEntity);

     а в Condition <T> - останется apply
     Condition <T> - отнаследуй от Matcher <T>
 */
********************************
 http://joxi.ru/12MDGYXu4DJZzm
 /*
    еще чуть разгрузить пекедж можно)
 */
**************************************

public class SizeOf extends AbstractCollectionCondition {
    protected int listSize;
    protected int expectedSize;

/*
    просмотри имена кондишенов (и классов, и методов для их вызовов)
    когда мы вызывали кондишены sizeOf(elementsLocator, 2)
    Of - был уместен
    теперь - при вызове sizeOf(2) - Of - уже лишний)

    просмотри и другие кондишены на этот предмет)

    насчет использования модификатора доступа protected

        есть такая точка зрения, что использовать protected - это самообман
        т к в рамках потомков можно для отнаследованного protected-метода
        этот метод сделать публичным

        когда мы использовали protected, мы хотели, чтобы что-то было с возможностью наследования
        и не хотели его внешнего использования.
        а кто-то отнаследовался от нашего класса и объявил это как public
        и вот то, что мы прятали внутри класса - уже "торчит" наружу

        есть good practice - избегать применения protected
        то, что мы что-то объявим внутри класса-кондишена как public
        не будет нам особо мешать при работе с нашим фреймворком
        т к в итоге - используем для кондишена тип интерфейс,
        и это позволит не светить нашими публичными переменными/методами
        когда будем юзать фреймворк

        идеально про протектед-методы
            http://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables
            http://joxi.ru/52akqzoUGnqYGr

            http://stackoverflow.com/questions/3631176/why-are-many-developers-opposed-to-using-the-protected-modifier-in-oop
            http://stackoverflow.com/questions/37011/should-you-ever-use-protected-member-variables
            http://stackoverflow.com/questions/4913025/reasons-to-use-private-instead-of-protected-for-fields-and-methods

            http://www.javalobby.org/java/forums/t77911.html

    Просмотри весь проект, перейди на использование public
*/
********************************************
public static final ElementCondition visible = new Visible();
...
//    public static ElementCondition visible() {
//        return new Visible();
//    }

/*
    по идее - так конечно короче)

    но - не так уж и хорошо)

    Тут есть такая тонкость)

    мы создали статические переменные = объект-кондишен

    и используем их в проекте, который поддерживает параллелизацию

    если мы в параллельных тестах будем использовать ОДИН объект-кондишен ОДНОВРЕМЕННО
    могут возникать странные ошибки

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

    вариант с методом - грамотнее)

    вернись к варианту с методом)
*/