Именование классов реализующий интерфейсы Java
HTML-код
- Опубликовано: 25 ноя 2023
- В этом уроке я рассказываю, как правильно именовать классы реализующие интерфейс.
Курс про Java www.job4j.ru/
Пробные IT собеседования Java, JS, Python, Go - checkdev.ru/
Петр, здравствуй! В феврале 2017 года пришел на курсы Петра абсолютным новичком, не знал в программировании вообще ничего. в течение года занимался на полщадке job4j, параллельно изучал JS, SQL. через год прошел собес на fullstack разработчика, сейчас руководитель отдела разработки, тимлид на нескольких проектах. Спасибо, Петр!!
Приветствую тебя, Петр! Спасибо, что продолжаешь развивать курс. Курс становится всё круче и круче! Да, он тяжел, особенно для тех, кто не был связан с программированием. Но благодаря тебе и другим менторам из твоей команды, курс постигается и потом, как следствие, можно найти работу программиста. Уже два года, как прошел твой курс и работаю Java разработчиком. Но с удовольствием просматриваю твои новые видео. Ещё раз спасибо тебе и твоей команде!!!
Нашёл для себя кое-что новое в этом видео. Спасибо большое!
Отлично, спасибо! Было интуитивное желание так делать, но не было примера. А теперь всё встало на свои места.
Поворчу по поводу того что имя интерфейса это существительное. А как же причастие =)
Я про те интерфейсы, которые используем чтобы описать максимально абстрактное общее поведение. Для примера, такие интерфейсы как Cloneable, Serializable, Iterable, Closeable, Throwable. Они все заканчиваются на *able и описывают поведение и поэтому обзываются причастием. Про интерфейсы такого типа можно тоже упомянуть
Ура, теперь в видосы в фулл хд! Пётр, сделай видео про OAuth 2.0
Вы лучший
В этом уроке я рассказываю, как правильно именовать классы реализующие интерфейс.
Курс про Java www.job4j.ru/
Пробные IT собеседования Java, JS, Python, Go - checkdev.ru/
Спасибо большое
Курс божественнен, но тяжёлый
Учился на курсе куда более тяжелом на субъективный взгляд. У Петра в этом плане очень сбалансированно.
Разбивать на пакеты это хорошо но как одинаковые имена из разных пакетов будут выглядеть в коде, это будет у одного класса просто названия а если будет еще один класс таким же именем будет длинная строчка импорта в самом коде . По моделям DTO, если предположить что я уберу шум DTO то при написании сервисов я буду часами гонять Джабу почему у меня не прилетело одно поле которое мне нужно а в итоге окажется что импорт не тот прилетел. По ДТО модели не понятно как правильно именовать. Надеюсь написал понятно.
По префиксам и постфиксам вопросы.
Вот есть у тебя энтити Car и есть дто-ха Car, как быть ? Придумывать какие-то непонятные названия вместо CarDto ? а зачем ? По интерфейсам и реализациям в целом тот же вопрос, зачем рожать велосипед, если есть стандартная дедовская практика с Impl (хотя мне с эстетической точки зрения тоже это не оч нравится) ?
Про репозитории, сам же сказал что мощная среда разработки, что мешает из реализации прыгнуть в интерфейс или из интерфейса в реализацию одним сочетанием клавиш ?
Ну и если уж группировать, то проще имплементации в отдельный пакет внутри пакета с интерфейсами
1. Энтити и дто это как теплое и мягкое. ДТО называйте как вам удобно, а лучше если с постфиксом дто. 2. Есть стандартная дедовская практика в перeчислениях запятую ставить не в конце строки, а в начале новой строки
public void method(String arg1
, int arg2
, bool arg3
, String arg 4)
Дедовская технология, пожалуйста пользуйся
3. Хоть сколько мощная у тебя среда, в крупном проектах хотелось бы что бы все группировалось очевидно, а не всю в одну кучу, когда раскрываешь пакет а там 50 классов и хрен что пойми