5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
наследование не нужно вообще в принципе, тем более что никто не понимает разницы между реальным реальным обогащением функциональности и "ща короче нахреначим абстрактный класс, там будет сто протектед методов, из которых для каждой реализации нужно не больше половины, зато напишем всё только один раз"
Читать полностью…
это цитата была, что спринг дата побуждает такой паттерн делать
Читать полностью…
привет. есть у кого-нибудь пример готового ипр, интересует middle->senior. ну или вообще любой в качестве примера, киньте если не жалко)
Читать полностью…
Чем что. Чем наследование. Наследование надо выкинуть как некачественный рудимент по-хорошему.
Prefer composition + zero boilerplate delegation как в скале и котлине + interface/ trait implementation. Об этом бесчисленное кол-во материалов (книги/ статьи/ видео) есть. И на практике выигрывает.
Low coupling, greater flexibility, ...
Прочитано, но также там и написано, что это не всегда лучше
Читать полностью…
Участник нашего чата @ivandasch сегодня выступает на HighLoad 2024.
Если смотрите HL, то заходите поддержать доклад Ивана!
Это тоже немного странное, правильнее было бы написать 1 сущность – 0+ репозиториев.
Если у нас структура пакетов поделена по фичам, то ничего не мешает аналогично создавать фичевые репо для этой сущности.
MyEntityCreationRepo, MyEntityProcessingRepo, MyEntityReportingRepo, MyEntityCleanupRepo и т.п. (очень условно). Когда логика сложная, это помогает соблюдать SRP на уровне репо.
Также стоит помнить о том, что если в оно нужен метод, тянущий другую сущность, не T, нет никаких проблем написать его в своём фича-репо (разве что описать явно через @Query).
И я бы ещё заикнулся о том, что методы для тестов нафиг не нужны в боевом репо -- гораздо проще написать рядом с условным MyEntityProcessingTest локальный репо MyEntityProcessingTestRepo, и дергать всё нужные запросы в нём.
Какие нафиг планы развития, проекты и только проекты, что делал реально на проекте, то и в активе
Читать полностью…
https://news.ycombinator.com/item?id=24443947
> According to Gosling, including classes/inheritance was his biggest regret.
Это лишь пазлик в общую картину. Как по крупицам в играх можно собирать кусочки в общую картину. И потихоньку понять, куда движется.
Везде кричат о SOLID, но фундаментальный, основной, поворотный "prefer composition over inheritance" как-то в тени сидит
https://youtu.be/hxGOiiR9ZKg?si=1-Cw3ODVDTrA3viM.
https://youtu.be/HOSdPhAKupw?si=iBi1g9SYoXhKYNWW
Использовать наследование классов OK тогда (никогда), когда точно знаешь, что система будет в будущем ровно такой, какую сейчас напишешь. Но это называется безумием знать будущее. Системы постоянно меняются. Композиция дает возможность менять структуру компонентов легче. А наследование классов наоборот как жесткая структура. Наследование прекрасно звучит на бумаге с собачками и кошечками наследниками животных, но в реальности кусок кода на наследовании классов - технический долг.
Но бывают случаи, когда невозможно без наследования классов, например, если интеграция с библиотекой только через наследование. Но это вынужденная мера.
Точнее было бы написать агрегация вместо композиции.
Еще интересно, что в Intellij IDEA есть пункт в меню рефакторинга "заменить наследование на композицию", но нету наоборот.
Четко написаны проблемы наследования классов также здесь https://en.m.wikipedia.org/wiki/Inheritance_(object-oriented_programming) и даны альтернативы. Пункт Issues and alternatives.
Достаточно оставляя включенной голову вникнуть в разные источники, попробовать на практике и сформировать картину
На практике композиция лучше в чуть ли не во всех случаях
Читать полностью…
В effective java очень хорошо об этом написано. Надо просто разок прочитать
Читать полностью…