@oop_ru
Viktor06.10.2018
15:04:48
15:04:48
ну тогда можно и эластику... просто опять же - основная ж проблема как я понимаю не в базе данных а в способе хранения.
если грубо то вот так фильтры хранятся =)
Sergey06.10.2018
15:13:57
15:13:57
сложна...
Viktor06.10.2018
15:15:04
15:15:04
если грубо то вот так фильтры хранятся =)
дальше для апдейта фильтра делаю селект
select DesignCtegory.id, Design.id, ImageTag.id, Product.id, Shape.id
from DesignCtegory, Design, ImageTag, Product, Shape /* here should be joins*/
where
DesignCtegory.id in (:selectedDesignCtegoryIds)
and Design.id in (:selecteDesignsIds)
and Product.id in (:selecterProductsIds)
and /*other filters here*/
and exist (select 1 from Template as t where t.designId = Design.id and t.productId = Prodcut.id)
который довольно топорный и медленныйну и второй селект для выборки продукта который относительно быстро работает
GoogleSergey06.10.2018
15:19:08
15:19:08
так, есть продукт, у него может быть несколько темплейтов, каждый имеет свой дизайн, каждый дизайн входит в какую-то категорию + есть тэги. При этом мы по итогу ищем продукты по тегу и категории темплейта...
то есть на самом деле мы ищем теймплейты... у которых категории и тэги могут храниться массивом айдишек и вся выборка будет проверять на пересечение множеств... что постгрес сделает довольно быстро (при условии наличия индексов)
Viktor06.10.2018
15:22:54
15:22:54
то есть на самом деле мы ищем теймплейты... у которых категории и тэги могут храниться массивом айдишек и вся выборка будет проверять на пересечение множеств... что постгрес сделает довольно быстро (при условии наличия индексов)
спасибо, можно попробоватьто есть на самом деле мы ищем теймплейты... у которых категории и тэги могут храниться массивом айдишек и вся выборка будет проверять на пересечение множеств... что постгрес сделает довольно быстро (при условии наличия индексов)
ты все правильно понял, ищем темплейты которых может быть овер 500к, а все остальное и есть фильтрыSergey06.10.2018
15:28:05
15:28:05
ты все правильно понял, ищем темплейты которых может быть овер 500к, а все остальное и есть фильтры
тут еще вопрос - можно ли по двум тэгам искать и какое там будет условие - что мол оба тэга или один либо другой?)Viktor06.10.2018
15:31:42
15:31:42
для одного типа категории - хотя бы один
для нескольких типов категорий - логическое и
как то так
Sergey06.10.2018
15:32:44
15:32:44
для одного типа категории - хотя бы один
для нескольких типов категорий - логическое и
как то так
ну это так, если там ИЛИ то сложные выборки можно заменить на статистику по каждой паре категория-тэг и потом тупо складыватьну так... короч это надо баловаться
но я не думаю что эластика для такой задачи чем-то сильно поможет, магии не бывает. Хотя опять же может чего про задачу не знаю
GoogleSergey06.10.2018
15:33:56
15:33:56
хотя не, сложение будет неправильно работать... ладно
Viktor06.10.2018
15:34:01
15:34:01
ну теперь есть пара идей для експериментов, буду пробовать, спасибо )
Роман06.10.2018
18:47:36
18:47:36
Вопрос:
Мне нужно сделать что-то похожее на Visitor, но с дополнительным условием.
Вот классическая реализация: https://refactoring.guru/design-patterns/visitor
interface Shape is
abstract method accept(v: Visitor)
interface Visitor is
method visit(d: Dot)
method visit(c: Circle)
method visit(r: Rectangle)
method visit(cs: CompoundShape)
Вот мне нужно, чтобы клиент моей библиотеки мог создавать свои реализации Shape и добавлять их в Visitor.
Вообщем не обязательно вообще использовать паттерн Визитор. Я с помощью него определяю тип абстрактного объекта и потом вешаю определенный обработчик для этого типа. Но нужно чтобы клиент мог добавлять свои типы и их обработчики.
В C# можно расширить интерфейс, т.е создать новый и унаследовать в нём старыйЭто на самом деле самый адекватный способ так, как библиотечная реализация визитёра априори не подходит под производные пользовательсие типы
Yury06.10.2018
18:57:52
18:57:52
В C# можно расширить интерфейс, т.е создать новый и унаследовать в нём старый
Но наследование же все равно надо прописывать? Если так то это ничего не меняет.Тут вот нашел решение, это все-таки делается через рефлексию в java. В C# по иде также должно быть.
Там же нельзя клиентом подменить интерфейс указанный в методе?
Вот что я искал.
https://sourcemaking.com/design_patterns/visitor/java/2
Рефлексия в рантайме. Правда перформанс от такого страдает, наверное стоит переделать, чтобы отрабатывала при старте только.
Дмитрий06.10.2018
19:45:06
19:45:06
Что люди не придумывают лишь бы с деревьями не связываться
Yury06.10.2018
19:54:57
19:54:57
Дмитрий06.10.2018
20:08:20
20:08:20
Такое рантайм расширение это просто неявно заданная иерархия
В ReflectiveVisitor в getMethod например можно заметить навигацию по иерархии
Дмитрий07.10.2018
17:11:48
17:11:48
10 Тони Роббинсов из 10
Павел07.10.2018
17:14:58
17:14:58
Возможно я не в теме) тони робинсон шут который срубил бабла все похлопали и он уехал. Что щначит 10 из 10 тониробнсонов относительно абзаца из книги) это значит что в точку или что не в точку?)
illiatshurotshka❄️07.10.2018
17:19:42
17:19:42
классное отношение "это решение плохое, оно угнетает мои желания о том как язык должен выглядеть"
Дмитрий07.10.2018
17:19:49
17:19:49
Возможно [при каких условиях?] слишком много [это сколько?] в некоторых ситуациях [каких?]
Я так курсовые писал
Налить побольше воды и готово
GoogleПавел07.10.2018
17:22:19
17:22:19
Ааа понятно)
Переизданное без воды)
Sergei07.10.2018
18:28:03
18:28:03
Отличная статья по теме - "статические методы УЛУЧШАЮТ инкапсуляцию".
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
Больше статических методов - больше ООП.
Scott Meyers не подведёт.
Sergei07.10.2018
20:11:48
20:11:48
Так-то рассуждения в статье более чем здравые - наличие статических методов говорит о минимальной необходимости доступа к внутреннему состоянию объекта.
Sergey07.10.2018
20:34:57
20:34:57
Так-то рассуждения в статье более чем здравые - наличие статических методов говорит о минимальной необходимости доступа к внутреннему состоянию объекта.
статические методы, раз уж ты их решился делать, не должны вообще со стэйтом работатьмаксимум с инициализацией помогать
иначе они не нужны ибо у тебя должен найтись кто-то чья обязанность это "что-то" сделать. Причем чаще всего оправдание статике - банальная лень (ну и экономия на диспетчиризации в условиях андроида и тамошней кривой Java VM)
Sergei07.10.2018
22:34:58
22:34:58
Статические методы позволяют повторно использовать имеющееся поведение объекта, вместо необоснованного повышения сложности.
Sergey07.10.2018
22:36:11
22:36:11
Статические методы позволяют повторно использовать имеющееся поведение объекта, вместо необоснованного повышения сложности.
да, глобальные процедуры очень хорошо подходят для снижения сложности. В основном потому что они глобальны, а стало быть мы можем не управлять зависимостями. Это ж сложно.либо я тебя не понял. Но мне сложно придумть ситуацию когда статические методы (которые нельзя описать как чистые функции) полезны (именно полезны а не являются следствием каких-то технических ограничений твоих фреймворков, опять же пинок в сторону андроида)
если ты можешь привести пример - было бы славно
Sergei08.10.2018
03:47:05
03:47:05
если ты можешь привести пример - было бы славно
https://gist.github.com/sleepytomcat/12402eeffd7f145731c4a51462b4b843если ты можешь привести пример - было бы славно
Положим, мы реализуем класс "прямоугольный треугольник", который среди прочего умеет посчитать нам длину своих катетов и гипотенузы.
В варианте (1) мы пишем "как будто правильное ООП" - реализуе все три метода, используя состояние объекта.
В варианте (2) - "плохое ООП", так как у класса для вычисления гипотенузы используется статический метод.Тем не менее в варианте (2) инкапсуляция существенно лучше, чем в варианте (1), так как в случае изменения внутреннего представления данных в первом варианте придется переписать три метода, а в варианте (2) - только два из них.
GoogleHerman08.10.2018
04:34:39
04:34:39
Совсем не ясно почему во втором случае нужно переписать только один метод, а в первом все три.
Sergei08.10.2018
04:36:01
04:36:01
Совсем не ясно почему во втором случае нужно переписать только один метод, а в первом все три.
В первом случае изменятся все три метода, во втором - только два.Herman08.10.2018
04:36:56
04:36:56
А, два. Почему нельзя в ооп варианте высчитать гипотезу через т. Пифагора?
Sergei08.10.2018
04:39:47
04:39:47
Можно, никто не запрещает. Но при этом компилятор никак не проконтролирует гарантию неиспользования внутреннего представления объекта.
Herman08.10.2018
04:39:58
04:39:58
Я бы вообще при изменении структуры данных новый класс бы написал.
Sergei08.10.2018
04:40:28
04:40:28
Я бы вообще при изменении структуры данных новый класс бы написал.
Но тогда и переписывать _весь_ использующий его код?Herman08.10.2018
04:40:52
04:40:52
А дальше интерфейсы
Можно, никто не запрещает. Но при этом компилятор никак не проконтролирует гарантию неиспользования внутреннего представления объекта.
А где там использование внутреннего состояния?Вот кстати в статическом методе очень велика вероятность залезть в состояние объекта, приватные поля-то доступны
Sergei08.10.2018
04:46:18
04:46:18
Sergei08.10.2018
04:48:26
04:48:26
Совсем не ясно почему во втором случае нужно переписать только один метод, а в первом все три.
Собственно статья Мейерса описывает этот подход подробнее http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197Herman08.10.2018
04:50:00
04:50:00
У меня есть в коде кусок кода вонючий. Выглядит так
sender.send(factory.create())
Вот тут то же самое, для вычисления гипотенузы нужно тянуть какой-то статический метод. А если у нас класс за интерфейсом, то какую реализацию тянуть?
У меня есть в коде кусок кода вонючий. Выглядит так
sender.send(factory.create())
Вот тут то же самое, для вычисления гипотенузы нужно тянуть какой-то статический метод. А если у нас класс за интерфейсом, то какую реализацию тянуть?
Я не знаю как точно называется этот code smell но ситуации похожиСобственно статья Мейерса описывает этот подход подробнее http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
Сам-то читал? "One implication of this is that it's generally a bad idea to move a free function into a class as a static member just to show that it's related to the class"Sergei08.10.2018
05:05:43
05:05:43
Но по вопросу "статические методы улучшают инкапсуляцию" разночтений нет?
Herman08.10.2018
05:08:07
05:08:07
Но по вопросу "статические методы улучшают инкапсуляцию" разночтений нет?
Если в джаве есть friend функции то вопросов нетSergei08.10.2018
05:09:18
05:09:18
Статью читал, конечно - первый раз довольно давно, когда ещё писал на C++. Там проблем с функциями вне класса нет, а с Java я совсем запамятовал, что у методов класса есть доступ и к приватным данным объекта. Так что да, по-хорошему эти статические методы ещё и вне класса должны быть.
GoogleHerman08.10.2018
05:15:24
05:15:24
Хм, а как это связано?
Так связано что в твоём примере ты делаешь ровно то что считается bad idea в статье которую ты скинул. Если перепишешь пример на c++ то может станет ясно. Ну и ещё на вопросы мои ты не на все ответил.Sergei08.10.2018
05:23:37
05:23:37
Обновил код https://gist.github.com/sleepytomcat/12402eeffd7f145731c4a51462b4b843
Aleh08.10.2018
08:00:40
08:00:40
https://trello.com/b/lgdFaPMY/links нашёл чью-то подборку ссылок неплохую)
https://gist.github.com/sleepytomcat/12402eeffd7f145731c4a51462b4b843
не понимаю, что значит better encapsulatedчто там такого better
Sergei08.10.2018
14:26:19
14:26:19
что там такого better
Изменение внутренней реализации меньше влияет на код, этот класс использующий - в этом смысле better.Aleh08.10.2018
16:09:16
16:09:16
Открыть в Telegram