https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names
/*
    учитывай конценшенсы для имен пекеджей

    когда ты меняешь лишь регистр буквы в названии -
    с точки зрения репозитория ничего не поменялось  (case insensitive)
    вот полезные линки про эту проблему
    https://www.patrick-wied.at/blog/rename-files-and-folders-with-git
    http://stackoverflow.com/questions/8481488/is-git-not-case-sensitive
    http://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git
    http://stackoverflow.com/questions/8904327/case-sensitivity-in-git
    http://stackoverflow.com/questions/3011625/git-mv-and-only-change-case-of-directory


    если это сложно, то можно поступить так

      если надо поменять лишь регистр буквы в названии (pageObject -> pageobject)
      и отразить эти изменения в репозитории

      1)добавляем к названию еще какую-нибудь букву/цифру (pageObject -> pageObject1)
      2)обновляем репозиторий
      3)корректируем название на нужный нам вариант (pageObject1 -> pageobject)
      4)обновляем репозиторий

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

*/
*************************
public static Condition<List<WebElement>> minimumSizeOf(int size){
/*
    Of - лишний)
    в прошлый раз было про это
*/
********************************
   public static Condition<WebElement> visible(){
        return new Visible();
   }
/*
    по идее - можно было еще короче)
*/

public static Condition<WebElement> visible = new Visible();

/*
    т е - реализовывать не метод, а статическую переменную
    вроде бы - лаконичнее, что хорошо

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

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

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

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

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

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

    наш текущий вариант с методом - грамотнее)
*/
**************************************
public class Visible extends ElementCondition {

    private Boolean actualElement;

    @Override
    public WebElement check(WebElement element) {
        actualElement = element.isDisplayed();
/*
    Сама реализация - ок
    а вот имя actualElement - странное

    actualState, isDisplayed - было бы уместнее

    вариант с actualState - хорош тем, что тоже можно будет реализовать кондишены
    present(), enabled(), visible() - используя одного общего предка

    вариант с  isDisplayed - хорош понятностью)

    с реализацией кондишенов и применением наследования - все ок теперь
*/
*****************************************
public class WaitFor {
...
    public <V> V until(Condition<V> condition, long timeout){
/*
    тут тоже все ок теперь

    переиспользуй этот метод в новом
    public <V> V until(Condition<V>... conditions)

    в котором  - применяй Configuration.timeoout
    и просто в цикле - вызывай until для каждого переданного кондишена по очереди
    в итоге - мы или выйдем ко исключению
    или вернем результат последнего выполненного until

    цель - получить инструмент для последовательной проверки нескольких кондишенов
*/
*******************************
http://joxi.ru/KAg8voQsgoX1qr
/*
    думаю, стоит переместить эти 2 класса в пекедж conditions
    глубже  по структуре  - не нужно это прятать
    а вот на уровень  conditions - было бы ок
*/
------------------------------------