00:00:00 Начало приветствие 00:01:52 Дисклеймер 00:02:29 Как мы пришли к этой теме 00:03:10 Интерфейсы. Как и когда их использовать 00:09:46 Наследование, особенности и минусы. Что будет если переборщить с наследованием... 00:17:42 Инкапсуляция 00:21:47 Обзор SOLID принципов 00:27:07 Обзор DRY, KISS, YAGNI 00:28:09 DAO Разделение хранилища и бизнес логики 00:31:18 Схема DAO и Сервисы 00:33:32 Почему не надо надеется на фреймворки 00:35:32 Почему используя все перечисленное не достаточно чтобы просто так написать хороший код 00:35:32 Вопросы и ответы
Насчет "наследование зло". Автор рассматривает частный случай, когда наследуешь свой класс от некоего левого (например из сторонней библиотеки), и при этом этот класс может в будущем непредсказуемо меняться (например, при обновлении библиотеки). Однако тут проблема вовсе не в наследовании, а в использовании любой вещи, которую ты не можешь контролировать по той или иной причине. Если наследовать от своих собственных классов или от классов своей команды, где любые изменения известны и контролируются, то пользы гораздо больше чем потенциального вреда.
Николай Алименков xpinjection.com/coaches рассказал про проблемы граммотного применения ООП в Java. До этого было несколько встреч клуба анонимных программистов xpinjection.com/uadevclub (30, 31 и 32 встреча), и этот доклад можно считать сжатым в час вводом в тему. Очень много практических советов - я прям во время просмотра открыл проект и переписал пару классов над которыми долго колебался :)
***** всё верно, и подробнее это отхоливарилось в четырёхчасовой 31й встрече. Есть видео. ИМХО презентации Николая не хватает визуализации, из-за этого возникает много недопонимания. С интерфейсами я считаю примерно так: они не помешают в любом случае: их легко создавать и перерефакторивать. А от некоторых редких проблем могут уберечь. Особенно это касается реально энтерпрайзнутых легаси проектов. Про темплейт метод Николай уже ответил в этом видео на вопрос из зала. Template Method легко преобразовывается в Стратегию.
Хорошо рассказывает про очередное правильное ООП, все это конечно хорошо, но столкнувшись с реальностью (сроки/деньги/менеджмент) все эти правильные методологии рассыпаются как карточный домик...
Эти принципы ни в коем случае не противоречат срокам/деньгам/менеджменту. Поскольку такой подход хоть и чуть более геморный, но все же сильно уменьшает количество потенциальных багов и улучшает поддерживаемость кода. Что потом очень благотворно влияет на те же самые сроки и деньги. Когда тебе дают фичу реализовать и ты ее реализуешь за полчаса, а не разбираешься в километровой лапше кода месяц, не понимая, что от чего наследуется, зачем и как сюда впихнуть новую функциональность, чтобы не сломать ничего.
на 25:55 dependency inversion principle: не заботиться о создании объектов самостоятельно, а получать откуда-то? Вы серьёзно? и как это соотносится с действительной формулировкой: Модули верхних уровней не должны импортировать сущности из модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Тупое добавление везде интерфейсов противоречит KISS. В дельфях property есть с 90ых годов. Если бы до этого не знал принципы ООП то, из этого доклада не понял бы о чём речь.
Противоречит или нет, это ещё вопрос. Например, переменные в языке по умолчанию могут быть финальные, а могут и не быть, а написание "лишнего" слова в любом случае будет "нарушением принципа KISS". Тут уде речь должна идти про особенности языка. Насколько я понимаю, интерфейсы нужны для того, чтоб 1) использовать статическую типизацию без кастинга 2) иметь возможность присвоить значение в виде объекта нескольким переменным разных типов, не наследуемых один из другого, и при этом 3) обойтись без множественного наследования полей объектов и тел методов. Были ли в дельфях интерфейсы?
Только он заговорил про KISS, YAGNI и что в 90% случаев тебе не понадобиться новый тип пользователя, как вдруг, кто бы мог подумать, начал говорить о DAO слое, который очень нужен, чтобы завтра, вдруг, срочно можно было легко сменить базу данных.
Смешной чувак. Наследование это плохо, потому что если унаследоваться от класа не предназначенного для наследования, могут возникнуть проблемы. Design for inheritance or else prohibit it, не? В джаве по умолчание класы не final и всем влом писать этот final, а потом приходят чуваки, как этот, наследуются от чего попало и плачутся, что у них все сломалось и наследование зло. Я чистил картошку, порезался. Ножи зло. Шел, наступил на банан упал. Бананы зло.
00:00:00 Начало приветствие
00:01:52 Дисклеймер
00:02:29 Как мы пришли к этой теме
00:03:10 Интерфейсы. Как и когда их использовать
00:09:46 Наследование, особенности и минусы. Что будет если переборщить с наследованием...
00:17:42 Инкапсуляция
00:21:47 Обзор SOLID принципов
00:27:07 Обзор DRY, KISS, YAGNI
00:28:09 DAO Разделение хранилища и бизнес логики
00:31:18 Схема DAO и Сервисы
00:33:32 Почему не надо надеется на фреймворки
00:35:32 Почему используя все перечисленное не достаточно чтобы просто так написать хороший код
00:35:32 Вопросы и ответы
Спасибо докладчику, разъяснил, зачем и когда нужен DAO.
Насчет "наследование зло". Автор рассматривает частный случай, когда наследуешь свой класс от некоего левого (например из сторонней библиотеки), и при этом этот класс может в будущем непредсказуемо меняться (например, при обновлении библиотеки). Однако тут проблема вовсе не в наследовании, а в использовании любой вещи, которую ты не можешь контролировать по той или иной причине. Если наследовать от своих собственных классов или от классов своей команды, где любые изменения известны и контролируются, то пользы гораздо больше чем потенциального вреда.
Николай Алименков xpinjection.com/coaches рассказал про проблемы граммотного применения ООП в Java. До этого было несколько встреч клуба анонимных программистов xpinjection.com/uadevclub (30, 31 и 32 встреча), и этот доклад можно считать сжатым в час вводом в тему.
Очень много практических советов - я прям во время просмотра открыл проект и переписал пару классов над которыми долго колебался :)
***** всё верно, и подробнее это отхоливарилось в четырёхчасовой 31й встрече. Есть видео.
ИМХО презентации Николая не хватает визуализации, из-за этого возникает много недопонимания.
С интерфейсами я считаю примерно так: они не помешают в любом случае: их легко создавать и перерефакторивать. А от некоторых редких проблем могут уберечь. Особенно это касается реально энтерпрайзнутых легаси проектов.
Про темплейт метод Николай уже ответил в этом видео на вопрос из зала. Template Method легко преобразовывается в Стратегию.
***** ага, понятно. Тогда, да, темплит метод имеет смысл
Алименков Top as always
Скажите пожалуйста, а слайды можно где-то взять??
Хорошо рассказывает про очередное правильное ООП, все это конечно хорошо, но столкнувшись с реальностью (сроки/деньги/менеджмент) все эти правильные методологии рассыпаются как карточный домик...
Правильно делает, что капает на мозги общественности и лицам, принимающим решения.
Эти принципы ни в коем случае не противоречат срокам/деньгам/менеджменту. Поскольку такой подход хоть и чуть более геморный, но все же сильно уменьшает количество потенциальных багов и улучшает поддерживаемость кода. Что потом очень благотворно влияет на те же самые сроки и деньги. Когда тебе дают фичу реализовать и ты ее реализуешь за полчаса, а не разбираешься в километровой лапше кода месяц, не понимая, что от чего наследуется, зачем и как сюда впихнуть новую функциональность, чтобы не сломать ничего.
на 25:55 dependency inversion principle: не заботиться о создании объектов самостоятельно, а получать откуда-то? Вы серьёзно?
и как это соотносится с действительной формулировкой:
Модули верхних уровней не должны импортировать сущности из модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
По сути, это принцип о том, что везде должны быть интерфейсы, то что зависимости должны откуда-то приходить это Dependency injection скорее всего
більше dto і трансформеров
Тупое добавление везде интерфейсов противоречит KISS.
В дельфях property есть с 90ых годов.
Если бы до этого не знал принципы ООП то, из этого доклада не понял бы о чём речь.
Противоречит или нет, это ещё вопрос. Например, переменные в языке по умолчанию могут быть финальные, а могут и не быть, а написание "лишнего" слова в любом случае будет "нарушением принципа KISS". Тут уде речь должна идти про особенности языка.
Насколько я понимаю, интерфейсы нужны для того, чтоб 1) использовать статическую типизацию без кастинга 2) иметь возможность присвоить значение в виде объекта нескольким переменным разных типов, не наследуемых один из другого, и при этом 3) обойтись без множественного наследования полей объектов и тел методов. Были ли в дельфях интерфейсы?
KISS про то, что код надо разбивать на небольшие простые части, а не о том, что как можно меньше символов писать.
Только он заговорил про KISS, YAGNI и что в 90% случаев тебе не понадобиться новый тип пользователя, как вдруг, кто бы мог подумать, начал говорить о DAO слое, который очень нужен, чтобы завтра, вдруг, срочно можно было легко сменить базу данных.
Он же сказал дальше что это не главная причина.
все ок. но как можно actor называть актером???
Смешной чувак. Наследование это плохо, потому что если унаследоваться от класа не предназначенного для наследования, могут возникнуть проблемы. Design for inheritance or else prohibit it, не? В джаве по умолчание класы не final и всем влом писать этот final, а потом приходят чуваки, как этот, наследуются от чего попало и плачутся, что у них все сломалось и наследование зло. Я чистил картошку, порезался. Ножи зло. Шел, наступил на банан упал. Бананы зло.
такое. в начале сказал, что вы можете много с чем не согласится
диванний аналітик 😂
Это что собрание инопланетян? Вообще ничего не понял...