О том и речь

+

Нажал экзекьют и все зависло)))

Предлагаю открыть для себя транзакции. Штука клёвая. Закатываешь инсёрты и каждые 1000-2000 строк коммитишь. Побыстрее должно быть

Ребят, помогите с cron. Как задать выполнение каждые 5 минут, с 9-20ч и по пн-пт

*/5 09-20 * * 1-5

?

В чем конкретное отличие делегирования от композиции? Читаю примеры, статьи. Для меня это вообще одно и то же. Не могу понять.

В чем конкретное отличие делегирования от композиции? Читаю примеры, статьи. Для меня это вообще одно и то же. Не могу понять.

А что там не так?

Впринципе и есть одно и то же

А разница то в чем?

А разница то в чем?

Ни в чем)

Эмм..

Серьёзно?

Ну даже вики так думает

Серьёзно?

В его исходном использовании, делегирование означает ситуацию, когда объект для предоставления определённого набора функциональности полагается на другой объект. В научной литературе это часто обозначается как консультирование (англ. сonsultation) или агрегирование.

А агрегирование - есть композиция

Ясно. Спасибо. Это на собеседовании могут вообще спросить?

А хз

Был у кого нибудь вопрос с этим связанный?

правильно говорят, что наследование лучше применять только в крайних случаях?

правильно говорят, что наследование лучше применять только в крайних случаях?

Да

ну скажем так

чаще у тебя есть классы

и ты из них выделаешь один супер класс

чаще интерфейс

реже класс

Просто напиши да

Проблема наследования в том, что твои наследники зависят от родителя

Если ты что-то не так сделаешь, то все может поломаться у некоторых наследников, так как когда ты меняешь код у суперкласса, то затрагиваются все подклассы

Если ты что-то не так сделаешь, то все может поломаться у некоторых наследников, так как когда ты меняешь код у суперкласса, то затрагиваются все подклассы

использую это как фичу

Когда у тебя маленькая иерархия, то это можно отследить

Ну наследование можно использовать, но обычно его всегда можно заменить на интерфейсы и это будет работать во много раз лучше

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

Но можно и отнаследоваться

Просто если ты в спринге пишешь контроллеры, то там вообще лучше на все делать интерфейсы из-за проксирования классов

это почему?

Просто если ты в спринге пишешь контроллеры, то там вообще лучше на все делать интерфейсы из-за проксирования классов

вообще нет

вот у меня есть проект на буте с интерфейсами, а есть без них

для быстродействия чтоле?

так делают во многом из-за сервис-ориентированной архитектуры

и в буте с интерфейсами я только лишнюю головную боль замечаю

Для тестирования тоже

и из-за того, что много имплементаций может быть

и для тестов тоже

для тестирования есть моки же

хотя наверное быстрее реализовать заглушку

для тестирования есть моки же

ты же понимаешь, что мок - это голый прокси

чем моки расписывать

а есть стабы?

вот стаба и есть реализация интерфейса

стаб = заглушка же, не

EntityManager

EntityManagerImpl

EntityManagerStub

ну как только научусь тестировать нормально так буду пилить интерфейсы

например такая структура, вот в стабе может быть тот же функционал, что и в импл, но работают с ин мемори хранилищем

Ты же не называешь классы в проекте так?

Impl?

XImpl

Ага

у меня так названо в прошлом проекте

обожаю так называть

и в текущем даже есть

Я не знаю, мне кажется это вообще не нужно

мне конечно не нравится как это выглядит, X и IX мне больше нравятся

ERROR: S client not available

тут как у вас в команде принято

так и пишите

Что это за бред, делаешь интерфейс и реализацию называешь просто имплементацией

Топкек

у нас в команде не принято делать интерфейсы

А в сигнатуре класса я не мог глянуть

шучу

Что это за бред, делаешь интерфейс и реализацию называешь просто имплементацией

ты на джаве 1 день пишешь?

ты на джаве 1 день пишешь?

Да

давно так принято в тысячах проектах и библиотеках

Ну плохо принято

Мне не нравится

предложи лучше

всем пофиг, что там тебе не нравится)

Так, мистеру Волцкову не нравится как сделано, переписываем код стайлы, постите на хабр и жаба реддит

Я что-то не видел такого кодстайла

Скинь а

вот что значит парсерсы писать, пацан в бункере отсидел

ну тебя даже не смущает, что идея сама генерит IMpl приставку по дефолту

ну ты предложи как лучше называть реализации интерфейсов

что как бы намекает

Описательным словом

что это много лет назад было принято

вот мне нравится например Абстрактные классы называть именно AbstractClassName

Аррэйлисты

Линкедлисты

Как в стандартной либе

окей, это кейс с большим кол-вом реализаций

а если их всего две три может быть?

Если одна - ок

Называй как хочешь