Основы. Что такое интерфейс? [RU] / Мобильный разработчик
Вставка
- Опубліковано 28 жов 2020
- Всем привет, по просьбе одного патрона выкладываю видео по основам Java/Kotlin.
Если вам интересны видео с основами, то пишите, что ещё хотелось бы увидеть :)
Напоминаю, что видео вначале выходят для моих патронов. Стать патроном можно по ссылке ниже
===========================================
Стать Патроном канала и получить доступ к уникальному материалу
/ mobiledeveloper
===========================================
Мобильный разработчик в других соц. сетях
=======================
Вконтакте - mdeveloper
Instagram - / nplau
=======================
Ставь лайк и расскажи друзьям, чтобы они тоже попробовали эту технологию
![Retrofit. Часть 1. Основы [RU] / Мобильный разработчик](http://i.ytimg.com/vi/mVx3_vSxbJU/mqdefault.jpg)
![Retrofit. Часть 1. Основы [RU] / Мобильный разработчик](/img/tr.png)
![Паттерны проектирования. Наблюдатель [RU, Android] / Мобильный разработчик](http://i.ytimg.com/vi/udXjNVpBnt4/mqdefault.jpg)
![Архитектура. SOLID [RU] / Мобильный разработчик](/img/n.gif)
Касательно дефолтных реализаций в интерфейсе хотелось бы дополнить. Их главная задача не столько давать именно дефолтное поведение при изначальном создании интерфейса, сколько позволять его расширять.
Допустим у нас есть интерфейс IExportable, у которого есть методы toXml() и toPDF(). Мы берем этот интерфейс и реализуем для различных документов в нашей системе(счета фактуры, заказы, заявки, служебные записки, документы материалов и т.д.) Через полгода бизнес решает, что определенный вид документа материалов(например, проводка переноса с одного склада на другой) они бы еще хотели выгружать в Word или Excel, чтобы их можно было редактировать. По хорошему мы должны добавить метод toWord()(или toExcel()) к нашему интерфейсу IExportable, но раньше бы это приводило к тому, что мы должны во всех классах которые реализуют этот интерфейс либо реализовывать этот метод, либо, как минимум, делать заглушку.
Внедрение же дефолтных методов в интерфейсах позволяет нам добавлять к ним функциональность без необходимости правки всех классов реализующих этот интерфейс. Например, мы можем сделать, что по дефолту там будет выгружаться пустой Word документ, где будет написано, что для текущего типа документов выгрузка в Word еще не реализована. А в нужном нам классе документа материалов мы реализуем уже полноценную выгрузку, при этом никак не меняя другие классы.
Это очень крутой пример, спасибо! Я его закреплю, пожалуй
а почему просто не создать несколько функций в файлике и не использовать их везде?
Вы: -Кис-кис-кис-кис!
Кошка: -Емпти саунд! Мяяяуу! Мяу!
😂
😂😂😂
Спасибо! очень интересны видео по основам Kotlin и Android, и было бы очень здорово их в отдельный плейлист
Я там в сообществе вопрос про курс задал ) был бы рад если бы вы тоже ответили
Очень круто! Спасибо за подробное объяснение
Раз плейлист про основы, то сюда и напишу) Вдруг время будет. Туплю по страшному про callback функции, никак не пойму в чем их фича. А Вы так понятно все объясняете, что если выйдет видео, то уверен ясности будет больше. Заранее спасибо, даже если не будет видео) Итак канал крут, и инфа прям нужная!
А можете конкретнее сформулировать запрос, что именно непонятно?)
@@MobileDeveloper Да вот озадачился попытаться вытащить ошибку при загрузке изображения с помощью Picasso. Обратился за советом к опытным товарищам как? Они дали ответ public void into(ImageView target, Callback callback)
____________
Этот callback имеет два метода:
class EmptyCallback implements Callback {
@Override public void onSuccess() {
}
@Override public void onError(Exception e) {
}
}
Я понимаю что это интерфейс callback функции, и понимаю что должен переписать методы. Но никак в толк не возьму а что именно написать в эти функции(((. Стал читать про коллбеки, а там как-то все ... воообщем суть не могу ухватить как с такими коллбэками работать. Если вопрос совсем тупой))) то заранее сорри)
Ну вопросы не бывают глупыми, особенно, когда человек хочет разобраться. Окей я понял, попробую сделать маленькое видео по этой теме
@@MobileDeveloper Спасибо большое
Развёрнуто и понятно, я доволен)!
Пожалуйста :)
Давно сюда не заходил,
Но превьюху заценил
Огонь! 👍
Спасибо, всё правильно. Идею поддерживаю, очень хотелось бы послушать про паттерны, более редкие, чем „фабрика" и „адаптер“.
Интерфейсы также используются в архитектуре MVP, чтобы View обращался к методам Presenter (теоретически их можно сделать несколько), а в тестировании можно заменить на фейковые (замокать). Тестирование без интерфейсов вообще сложно сделать.
Также интерфейсы удобны, если есть множество реализаций одного и того же (разные адаптеры, Http-клиенты), а абстрактный класс ради этого писать нет смысла, т.к. нет общей логики.
Удобно писать интерфейс для коллбэков (обработчиков нажатий).
Насчёт паттернов сделаю мои любимые наблюдатель и строитель )
@@MobileDeveloper инспектор и гастарбайтер? )
Хахах ) ну так-то да )
Что бы вы посоветовали для человека, переходящего из другого стека(энтерпрайз, SAP, немного JS): android или ios? Особенно с точки зрения востребованности на рынке и ЗП.
iOS чуть более востребован в плане, что зп у них обычно повыше. А в остальном все фигня, кроме пчёл. Выбирайте какая платформа вам больше нравится будете кайф ловить ) я вот до сих пор не могу определится мне и айфоны нравятся и андроиды )
Спасибо
Пожалуйста
Выпустите еще одно, более подробное видео на эту тему, с примерами на самые разные темы. Посмотрел очень много роликов у вас по либам RxJava, Moxy, Dagger, AsynkTask и т.д. Убедился, что Вы - профи и с немалой толикой преподавательского таланта (что-ли...?).
Дело в том, что делаю сейчас проект с кучей фрагментов, с разными ролями пользователей, авторизациями, поднятием и контролем вебсокетов и т.д. После просмотра Ваших видео понимаю, что нужно провести глобальный рефакторинг с переходом на интерфейсы, т.к. в некоторых видео Вы их используете и, чую, очень грамотно и к месту + я начинаю не понимать как вообще местами работает приложение(мною же написанное от и до). Мне непонятно по какому принципу можно выделить интерфейсы, что в них пихать, в чем преимущество? Тема крайне актуальная, не хватает чутка понимания, чтоб как озарение "Вот!!!Наконец-то я чувствую как это сделать!!!"
В этом видео нет понимания почему просто в каждом фрагменте тупо не написать функции с теми же названиями, не имплементируя интерфейс. В этом примере это не кажется необходимым, а с неопытного взгляда кажется еще и избыточным...
View.OnClickListener - это же абстрактный класс, не интерфейс, так? Ведь onClick выполняет всегда функцию нажатия, следовательно, есть базовая функция описывающая это поведение, а в интерфейсах ничего точно определить нельзя, но тем не менее в методе onClick можно написать любое поведение при клике.
И в новом видео очень бы хотелось наглядную разницу между интерфейсом и абстрактным классом.
Спасибо за прочтение!
Водитель существо свободное - куда хочет туда и едет) вам никто не мешает писать все функции прямо в классе и не использовать для этого интерфейсы. Просто интерфейсы дают хорошие возможности для гибкой архитектуры. Если вам нужны эти возможности, то берёте и делаете через интерфейс, если нет, то не делаете) все ведь просто )
@@MobileDeveloper Мне нужно их понимание, это точно! Чтоб, как Вы говорили в своем видео про таланты, не тупо их пихать куда надо и куда не надо, а использовать их как инструмент, с умом. Для этого нужно понимание.
Сделайте, пожалуйста, более развернутое видео на тему интерфейсов и абстрактных классов с примерами.
@@MobileDeveloper Ну и наверняка это плохой тон писать все тупо прямо в классе, чтоб он разрастался до тысяч строк кода...Да и путаться начинаешь, что вообще откуда, как и написал ранее...
Ну класс на 1000 строк это плохо да )) тут можно почитать что такое solid и стараться следовать этим правилам. Плюс подключить линтер и включить ограничения которые он даёт на размер класса, функции и так далее
Мне больше нравится определение интерфейса - механизм множественного наследования.
В том числе и это )
Есть ли у вас видео "Книги для начинающего мобильного разработчика"?
Нет, такого видео нет
Расскажите про функциональные типы Kotlin'а. В частности хотелось бы услышать Вашу интерпретацию, в каких ситуациях уместно делать у функций возвращаемый тип функцией? пример: fun someFunctions(a:Int, b:String):(param1:Int)->Boolean
Интересная мысль, можно рассказать чем функциональный подход отличается от остальных ))
А что делает класс зверинный прайс в вашем коде?
Можно тайм код пожалуйста)
@@MobileDeveloper 7:08 строки 11, 15, 16
А как какать? (сори, не удержался)
Еще интересно было бы про основы многопоточности, типа blocking/nonblocking; основы реактивности про паттерн Observer например.
Ну, опять же говорю меня попросили сделать, поэтому я сделал.
Для многих очевидные вещи совсем не очевидны. Особенно для начинающих. Автора я полностью поддерживаю. Если все так разжевывать, то, возможно, общий уровень начинающих будет выше. Мне в свое время не хватало подобных видео...
@@beeline09 так я только за, даже темы предложил
Чтобы до конца осмыслить что это такое нужно просто для начала принять тот факт что есть такая штука, которая заставляет тебя реализовывать методы.
И жить с этим, изучать, развиваться дальше... А потом такой ну интерфейс да интерфейс какие тут могут быть вопросы)
Ну в целом да :)) но раньше был популярный вопрос типа чем абстрактный класс отличается от интерфейса) так что там была идеология
@@MobileDeveloper и какой выберете: Thread или Runnable? Тогда с трудом отвечал, сейчас вообще не отвечу. 😃
@@alexandernifanin7366 так тред не абстрактный класс) его создать можно ) да и Runnable тоже можно )
Основы то что нужно, а то некоторые каналы напишут самые азы и имеют по 200-300к просмотров за ролик
Эх как бы и мне получить 200-300к просмотров
@@MobileDeveloper выпускать всякую дичь, аля как сделать игру на android и там змейку какую-нибудь сделать и прочее
Хм надо подумать ))
@@MobileDeveloper сделай как делать кастомные view))
Моя самая нелюбимая тема ))
Получается, что интерфейсы - вариант "принудительной напоминалки"? Или в чём еще преимущество их использования?
Механизм множественного наследования и легкая подмена. Вот два основных преимущества
@@MobileDeveloper Прошу прощения за беспокойство, просто когда ты туговат, хочется всё своими словами понять и желательно правильно))
С множественным наследованием интерфейс выступает в роли прослойки, позволяющей это самое множественное наследование реализовать, правильно?
Получается у нас есть нужная реализация чего-либо и дабы не повторяться мы создаём интерфейс, его наследуем от класса с необходимой реализацией и уже этот интерфейс можно реализовывать, хоть пятидесятым в списке, в классе куда эту функциональность нужно добавить, так?
А под легкой подменой вы что подразумеваете?
И еще немного фэйспалмов от знающих, но всё же.
В вашем примере, вы от интерфейса делаете две разные реализации. У меня возник только один вопрос, видимо тупой конечно, чем будет хуже, если вот прям там, удалить код интерфейса и в классах убрать override? Просто с позиции не знающего меня - остаются те же две реализации.
Ничего страшного ) нормальные вопросы. Насчёт множественного наследования вы все правильно поняли.
Насчёт подмены. Мой любимый пример это аб тест в приложении. 50% видят одну навигацию, а 50% другую. В целом она одна и та же, в плане, что там нужно сходить, допустим, и там и там в деталку продукта и в отзывы на продукт, но сами страницы отличаются. В таком случае интерфейс у вас выглядит одинаково. RouteToDetail и RouteToReviews. А вот реализация будет разная. И вот у вас две реализации RouterV1 и RouterV2.
И дальше вы поле создаёте у 50%
val router: Router (это интерфейс) = RouterV1()
А у других 50%
val router: Router = RouterV2
Возможно это благодаря как раз интерфейсу )) в этом и подмена
@@MobileDeveloper Благодарю, проясняется головушка понемногу))
Пожалуйста )
Усиливай звук пожалуйста, ничего не слышно
прибавь сам
Да вроде делаю нормализацию. Может погромче сделать?
@@MobileDeveloper у меня на телефоне на полную, но холодильник даже глушит. Другие ролики по ощущением в 1,5 раза громче
@@MobileDeveloper а за ролик спасибо, сам столкнулся в котлине, что интерфейс теперь и методы предопреденные иметь может) и необходимость абстрактных для себя объяснить не смог, тк джаву учил ещё 6
@@MobileDeveloper когда готовишь, чужие видео слышно лучше.
Лично мне подобные видео нужны, изложение хорошее, но в Android Studio все очень мелко. И да, Алексей, убей Матвея об Павла, потому что в отличие от прослушивания, смотреть на это невозможно. Это реально может убить глаза и вестибулярный аппарат
Спасибо, сейчас думаем над тем как оформлять все это идеально