Абстрактные классы и интерфейсы в Java - не одно и то же!

Очередное обучающее видео по языку программирования Java для новичков.
В течение видео я пару раз оговорился и сказал "реализация" по отношению к абстратному классу. Обращаю ваше внимание что это не верно.
Важно отличать! Про родительский класс (абстрактный или нет) мы говорим что наш класс его наследует или наследуется от него. А вот интерфейсы мы реализуем.
Приятного просмотра!
0:00 - Приветствие
1:28 - Абстрактный класс
16:09 - Интерфейс
27:23 - Итог

[@akberendarhankyzy1075]

Вы очень хорошо объясняете. Пожалуйста выпускайте больше видео про ООП.

[@user-vb6rs4uj7y]

классно объясняете, жаль больше нет видео на канале

[@pabloescobar-us1kl]

Классное объяснение, рад тому что натолкнулся на данное видео

[@_vist]

Посмотрел несколько видео на эту тему, у вас самое понятное объяснение!!! 👍🤝

[@user-tu4uz5qp9x]

Спасибо за урок! Легко объясняете! Давайте по возможности больше уроков!

[@Noyvel]

Огромное спасибо за Ваш труд. Снимайте пожалуйста больше видео.

[@AngelCheater]

В интерфейсе могут быть поля, но они по умолчанию public static final - то есть константы. А так отличное объяснение!

[@arven4430]

"программисты - староверы" ахаха 😄. За вставку с газ 66 отдельный респект

[@johnconnor3553]

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

[@user-ql3rm2ci3w]

Он тоже круто про java объясняет?

[@user-sq1ol8xo6g]

Очень хорошая подача материала, спасибо! Снимайте ещё ❤

[@zexceed8880]

Надеюсь вернётесь на ютуб снимать видосы

[@09Vanek]

Слушай Игорь! Вот ты просто красавчик!!!👏👏👏

[@user-ut9yn2ux7n]

все понятно и просто обьяснил ,жду следующие видео

[@user-tm3uz6ij8t]

Еще есть такой момент: у интерфейса все его методы public. Соответственно, реализованные методы интерфейса в классе всегда будут public. То есть, эти методы можно гарантированно вызывать из других классов. И это часть контракта. А вот при наследовании у переопределенного метода модификатор доступа необязательно может быть public.

[@user-wq9gc4rj3w]

Очень ценное замечание, спасибо. Поправлю только в том что в современной Java (начиная с Java 9) реализована возможность присвоения модификатора private методам интерфейса, но с некоторыми ограничениями. Эти методы могут использоваться только внутри самого интерфейса. То есть к ним неприменимо понятие default т.к. они в любом случае не переопределяются в классах реализующих данный интерфейс. Так же они могут быть статичными, если используются в статичных методах интерфейса. Я счёл что эти подробности перегрузят видео цель которого помочь разобраться в разнице между абстрактными классами интерфейсами. Но я согласен с вами что эта тема тоже заслуживает внимания.

[@roottor]

Все отлично - спасибо !!!

[@irinaresetnicova4583]

Почему нет новых видео? Очень хорошо объясняете)

[@Biforzz]

тернарные операторы нужны. Еще интересно про дженерики

[@user-pt9lw3bh5j]

Поддерживаю тему дженериков.

[@hsjsudve837d]

отличия: 1) абстрактные классы содержат логику реализации, интерфейсы только обещают, что классы которые заимплементируют данный интерфейс обязуются эту логику реализовать 2) интерфейсов может быть множество заимплементированно, однако наследование может быть только единственным 3) модификаторы доступа в интрфейсе только паблик по понятным причинам(так как мы не реализовываем логику в интерфейсах), однако в абстрактном классе может быть сколько угодно приватных методов чтобы в конечном счёте для потомков и так дать доступ к паблику который реализовывает возложенную на данный класс задачу вот основные отличия

[@user-wq9gc4rj3w]

Всё верно кроме п.3 в Java 9+ итерфейсы могут иметь приватные методы с реализацией.

[@Rommel7755]

Веселое видео. Автор говорит, что интерфейс отвечает за поведение и тут же прячет за него класс машина. И опять 25. На само деле машина должна быть либо абстрактным классом либо реализующим абстрактный класс а за интерфейсом классы с имплементацией в данном случае от Transportable, например TransByTrain, TransbyShip. т.е каким образом производится действие перемещение, доставка и т.п. Потом ссылка на интерфейс прописывается в абстрактном классе. А все вместе это будет называться паттерн проектирования «стратегия».

[@user-tm3uz6ij8t]

21:45 Хм, я раньше думал, что если на объект Car будет ссылаться переменная типа интерфейса Transportable, то "полем видимости" этой переменной будут только реализованные методы интерфейса Transportable. Другие же методы и поля класса Car будут вне видимости. Но оказывается, если переменные класса Car подсовывать в методы интерфейса Transportable, то они там 'засвечиваются'.

[@user-wq9gc4rj3w]

Поведение переменной определяется тем какой объект в неё положили. А что вы имеете в виду когда говорите "засвечиваются"?

[@user-tm3uz6ij8t]

Я имею в виду, что переменная car типа данных Transportable "смотрит" на объект new Car(......) как бы через трафарет, который скрывает от этой переменной собственные поля и методы класса Car, а даёт видеть только методы предоставленные интерфейсом Transportable. Однако, если в реализацию метода go() включить поле name или вызвать какой-нибудь метод класса Car (если бы они там были), то их присутствие проявляется(!). Но напрямую такие вызовы для переменной Transportable не сработают: car. name; //даже в случае с public car. openDoor(); // метод класса Car

[@user-wq9gc4rj3w]

@@user-tm3uz6ij8t никакого трафарета нет. Как и нет никакой разницы как объявить переменную. Независимо от того, объявлю я переменную как Car car ... , Transporable car ... или любым другим абстрактным классом или интерфейсом, содержаться в этой переменной будет то что написано в правой части выражения, а именно ... new Car() - и именно это будет определять какие поля и методы есть у переменной. То есть в любом случае данный объект будет видеть всё что есть в классе Car, все поля и все методы, переопределённые или объявленные в классе Car разницы нет. Проще говоря эта переменная будет содержать в себе new Car() независимо от того как она объявлена.

[@alenache1]

@@user-wq9gc4rj3w человек имел ввиду, что апкастинг накладывает ограничения на доступ в коде к полям и методам, отсутствующим в интерфейсе. Компилятор просто не даст вам к ним обратиться.

[@ilgistoktogulov7270]

обьяснение по принципу KISS. Просто класс?

[@clannajebyan]

У вас VS, получается, вы еще на C# или C++ программируете?

[@user-wq9gc4rj3w]

На C# да. На моей текущей работе это необходимо.

[@clannajebyan]

@@user-wq9gc4rj3w классно. моя мечта была перейти на C#, но материалов практически ноль, хоть на англ, хоть на рус. Я живу в Америке и тут очень популярен C#.

[@user-wq9gc4rj3w]

@@clannajebyan к сожалению я вам тоже вряд ли помогу в его освоении т.к. сам осваиваю его на ходу. Моя с ним работа заключается в обслуживании чужого кода, иногда написании макросов, ну и пару небольших REST API написал. Правда на чистом C# без фреймворков т.к. как вы правильно сказали материалов очень мало по нему.

[@clannajebyan]

@@user-wq9gc4rj3w ну что вы, вы же не Джин - исполнитель желаний))) на чистом - это вообще шикарно🙂Засеньйорюсь в Java и пойду вас догонять по C# 😀

[@user-wq9gc4rj3w]

@@clannajebyan Отличный план. После Java остальные языки кажутся простыми. (кроме C++)))

[@alenache1]

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

[@user-fl4yw1cr7d]

Это нужно потому что расширять можно только один класс в java.

[@_vist]

Посмотрел несколько видео на эту тему, у вас самое понятное объяснение!!! 👍🤝