public static void setDriver(RemoteWebDriver setDriver){
        driver = setDriver;
    }
...
     @BeforeClass
    public static void setUp() {
        setDriver(new FirefoxDriver());
    }
/*

    лучше - вот так

     private static WebDriver driver;

     public static void setDriver(WebDriver driver){
          ConciseAPI.driver = driver;
     }

     т к оперируешь полем класса - к нему можно доступиться так - <имя класса>.<имя поля>
     оперировал бы полем объекта - тогда this.<имя поля>
************
    зажав сtrl  - кликни на FirefoxDriver
    и также - на RemoteWebDriver

    public class FirefoxDriver extends RemoteWebDriver implements Killable
    ...
    public class RemoteWebDriver implements WebDriver, JavascriptExecutor,
        FindsById, FindsByClassName, FindsByLinkText, FindsByName,
        FindsByCssSelector, FindsByTagName, FindsByXPath,
        HasInputDevices, HasCapabilities, TakesScreenshot


    а  WebDrive - это уже интерфейс

     уточняться в типе параметра ни до FirefoxDriver, ни до его предка RemoteWebDriver - не нужно
     все вебдрайверы приводятся к WebDriver

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

            WebDriver - это интерфейс
            RemoteWebDriver (а значит и его потомок FirefoxDriver) - это класс имплементирующий такой интерфейс

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

            немного забегая вперед
            вот это почитай
            довольно неплохо изложено
            полезные линки по интерфейсам
                 http://kostin.ws/java/java-abstract-and-interfaces.html

                 http://developer.alexanderklimov.ru/android/java/interface.php

                 https://docs.oracle.com/javase/tutorial/java/concepts/interface.html


            Статья про нейминг - интерфейсы + классы
            http://www.vertigrated.com/blog/2011/02/interface-and-class-naming-anti-patterns-java-naming-convention-tautologies/
            Вот это тоже важно
            http://stackoverflow.com/questions/1932247/abstract-classes-and-interfaces-best-practices-in-java
            http://joxi.ru/E2pdR1lFB1pyM2

            Сейчас - разбери это в общих чертах
            потом - когда будем это использовать на практике - окончательно разберешься
*/
/*
    сразу приведу текст Якова - про принципы ООП вообще и абстракцию в ООП в частности
    был как-то диалог про собеседования и про вопросы про принципы ООП )
    в ключе текущего вопроса - тоже полезное чтение)

    http://joxi.ru/YmE86l3I00oeMr
    https://en.wikipedia.org/wiki/Abstraction_(software_engineering)#Abstraction_in_object_oriented_programming

    Про те що принципів явно більше ніж 3:
    http://joxi.ru/D2P4XNdfppolv2
    https://en.wikipedia.org/wiki/Object-oriented_programming

    Про те що значить насправді ООП на думку того хто його взагалі придумав (Алана Кея):
    http://joxi.ru/E2pVN7ps996wvr
    http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

    Цитата:
    OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things.
    Перекладаю:
    ООП
    =
    1 надсилання повідомлень між обьектами (чого в джаві і близько немає доречі)
    2 інкапсуляція
    3 динамізм (тобто не статична як в джаві а динамічна типізація, як в пітоні наприклад чи рубі...)
    А ще є чуваки типу Єгора, які от таке про ООП пишуть: http://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html
    От тобі і список принципів )

    Наслідування реалізації - це загалом ЗЛО, і вже його включати в принципи ООП - це гріх доречі :) і збочення :)
    Більшість шарящих прогерів плюються від цього :)

    Десь на відео, вже не пам'ятаю де, я мав казати що під абстракцією можна розуміти багато що...
    Що базово - це просто винесення певних асбтрактних шарів... створення методу довкола шматка коду - це вже абстракція...
    Але в ООП ще під цим мається на увазі саме створення Абстрактних класів і інтерфейсів...
    Які дозволяють робити "наслідування інтерфейсів" (а не реалізації) і завдяки поліморфізму
    (якщо бути точним сабтайпінг-поліморфізму) досягати більш гнучкої і "загальної-асбтрактної" поведінки у об'єктів..
    І це і просто "створеня" методів довкола коду - це абстракція, але ця от "ооп-ешна" абстракція - якби "абстракція наступного рівня",
    яка дає в ООП ще більше можливостей... (не тільки в ООП доречі це є... )...
    При цьому ніби і без неї можна жити... Тобто є механізми як і без цеї фічі ніби прожити... Але в таких мовах як джава - без цього ніяк...

    Це буквально є окремою фішкою ООП (ну ооп-джава-стайл).
    Якби серед трьох принципі: інкапсуляція, наслідування, поліморфізм - під наслідуванням розумілось наслідуваня ІТЕРФЕЙСУ
    а не реалізації (тобто по суті і є ця абстракція про яку я кажу) - то тоді б "домовляти четвертий принцип сенсу було б не багато",
    але там розуміється саме "реалізації", тому я завжди роблю наголос ще на тому що є і "четверта абстракція"... бо без неї був би "неповний опис"...

    Можна було б сказати що "поліморфізм" теж включає у себе цю абстракцію...
    тому що поліморфізм теж реалізовується в джаві через наслідування...
    але знову ж  - і наслідування реалізації і інтерфейсів... тому трохи розпливчато виходить, не точно...
    а коли про абстракцію цю згадуєш в тому сенсі що я писав вище - то все роставляється на свої місця :)

    А взагалі то - от той список що на вікіпедії з семи пунктів - самий адекватний ;)
    Але знову ж таки, в ООП все дуже складно...цей термін вже так "походив по рукам",
    і такі мови як джава - так його спаплюжили (після оригінальних ідей Алана Кея) -
    що якщо хтось там починає плюватись від четвертого принципу - то це свідчить про те що він явно не шарить історії і не розуміє всієї глибини :)

    Мораль - не треба тут заморачуватись сильно, і якщо хтось на співбесіді буде до цього придиратись - то він задрот - і нафіг його.
    Головне це знання і розуміння фішок... Пофіг скільки ти назвеш принципів і під якими номерами...
    головне розуміти як створюються об'екти (інкапсуляція), і як робити їх поведінку "універсальною"
    (абстракція - тобто наслідування від абстрактних класів і інтерфейсів, яка працює через підтримку поліморфізму)
    От і все, що достатньо на співбесіді розказати, і бажано привести приклади на всі ці штуки.

*/
***********************
public class GmailPage extends ConciseAPI{
/*
    не надо тебе наследования
    можно работать со статическими методами ConciseAPI и с пейджа

    более того - пейдж можно опять реализовать как пейдж-модуль
    ну то если захочешь
*/
***********************
/*
    в этой работе - учти ревью к прошлой работе
    часть ошибок переехала и сюда)

    не повторяюсь
*/