Artem Gapchenko

В чем отличие абстрактного класса от интерфейса в Java?

Все упирается в понятие "тип". В былые времена, то есть во времена языка Simula, из которого черпали вдохновение создатели C++, были только классы. И на классах базировалась система типов. Причем механизм наследования был реализован так, как реализован, исключительно для экономии памяти, которая в те времена была очень дорогой.

Для того чтобы достичь полиморфизма, мы должны иметь возможность объявлять абстрактные типы. Мол "любая хрень которая имеет такой тип будет работать как надо". Потому в языках типа C++ появились абстрактные классы. Поскольку иногда нам хочется делать композицию абстрактных типов, в C++ реализовали множественное наследование.

В Java, которая во многом черпала вдохновения из C++ и smalltalk, решили ввести еще одну сущность - интерфейсы. Это был своего рода упрощенный способ задать абстрактный базовый тип. По итогу чтобы не решать проблему бриллианта (или ромба) от множественного наследования было решено отказаться и дать возможность классам имплементить несколько интерфейсов.

За счет этого мы получаем возможность делать композицию типов как мы захотим. То есть вся разница сводится к тому, что при наследовании от абстрактного класса, мы именно наследуем классы, в то время как интерфейсы позволяют нашим классам имплементить абстрактные типы.

В целом абстрактные классы нужны тогда, когда вам нужно наследование. Обычно это в ситуациях, когда у вас есть несколько классов, которые должны иметь общий абстрактный тип (то есть нельзя выделить наиболее слабого по ограничениям предка). Например если мы делаем цепочку классов String <- Email, то тут нет смысла в абстрактных классах так как тип String уже включает в себе подмножество типов Email.

В целом в java8 уже ввели возможность интерфейсам иметь базовую реализацию, так что не удивлюсь если со временем от ключевого слова extends в принципе откажутся, избавившись от лишней сущности.

Так же рекомендую к прочтению: www.javaworld.com/article/2073649/core-java/why-ex...

JDBC- интерфейс для sql-запросов. Работаете с голыми sql-запросами и оперируете таблицами, строками, колонками и значениями. Если результаты запроса нужно положить с объекты, то сами их туда распихиваете.
ORM - интерфейс для мапинга классов на таблицы, строки, колонки и значения базы данных. Работаете с java-объектами, sql-запросы за вас формирует ORM. Другими словами, не задумываетесь (почти), каксоставить sql-запрос, вытащить из него данные и раскидать значения по своим классам.
Предпочтительнее конечно работать с ORM, так как все за вас будет оптимизировано и закешировано. Конечно, нужно будет знать, не только как работает ваша база данных, но и как работает ваш ORM.

Можно сделать вот так, чтобы функция работала для произвольного числа аргументов:

def build_graph(x, *arg):
    for a in arg:
        # Цикл отработает столько раз, сколько передано аргументов после x
        # перебирая их по одному
        # и подставляя каждый из них в качестве 'a'
        plt.plot(x, a)
    #Всякие украшательства, подписи осей, легенда для графика и проч.

Genymotion

Что такое адаптер?

Смотрите. Есть у вас например micro USB кабель. И есть дырка в новом макбуке - Usb type c. Друг в друга они, как вы понимаете, не втыкаются. И можно взять адаптер microUSB -> USB type-c.

В этом суть адаптера. Конвертация интерфейсов. Мы сделал интерфейс штуки которая нам нужна, потом взяли готовую штуку которая вроде бы то что нам надо делает, и сделали адаптер, который закрывает нестыковки в интерфейсах.

Таким образом если вдруг через месяц обнаружатся проблемы, вы сможете заменить "готовую штуку" на другую готовую, сделать другой адаптер, и все. Изменения с точки зрения кода, который использует нужный нам интерфейс, будут только в используемом адаптере.

За счет этого достигается независимость.

Что значит "принимает зависимость"?

Предположим у нас есть метод для смены пароля юзера. Что бы это безопасно провернуть, нам надо пароль захэшировать и хранить в захэшированном виде. То есть нам нужна какая-то штука, которая будет эти пароли хэшировать. Мы о ней знать ничего не хотим, хотим что б нам ее давали:

public function changePassword(string $password, PasswordEncoder $encoder)
{
    $this->password = $encoder->encode($password);      
}

Это зависимость нашего метода. Он зависит от него. Диалог между объектами можно представить себе такой:

- Слыш, поменяй пароль на этот
- Оке, только хэшер паролей мне дай, мне очень надо
- А какой тебе?
- Да любой с этим типом
- Ну ок. На вот пароль и хэшер. Делай дела.

Что такое вообще эта зависимость?

Зависимости - это все что мы используем чтобы сделать дела. Это не только библиотечки, но и просто классы, функци и т.д. Весь "сторонний" код с точки зрения нашего кода. И самое важное в том, что "нашим" кодом является тот, над которым мы работаем в данный момент времени, а не все что мы написали. Даже функции, которые есть в языке программирования из коробки являются зависимостями. Вот только от них вам не деться никуда особо, а потому с ними замарачиваться не стоит. Или если есть долговременная поддержка у библиотеки и она устаялась - тоже можно просто использовать. А вот если это поделка на гитхабе с 10-ю звездочками и там до сих пор нет ни одного релиза - но она вам вот очень нужна, возможные поломки в ней (а они рано или поздно будут) стоит "закрыть" адаптером что бы потом поменять на что-то получше или обновить без боли.

Github