SK
А я в своё время охреневал от implicits и макросов в Scala
Я от имплиситов до сих пор охреневаю. Как вижу в туториалах имплисит, все - сразу к скале отторжение.
Size: a a a
2018 November 09
SK
Ничего не могу с собой поделать
RK
у меня наоборот - возможность через них подмешать нужные тебе вещи в существующие классы например оч не хватает в Java
SK
у меня наоборот - возможность через них подмешать нужные тебе вещи в существующие классы например оч не хватает в Java
Я в дажве дизайню классы так чтоб не надо было в них ничего подмешивать. Какой вообще прок в подмешивании чего либо в заведомо single-responcible класс?
RK
Да, есть ООП, да, есть наследование, но когда тебе нужно добавить ровно один метод - наследоваться жутко впадлу
SK
Да, есть ООП, да, есть наследование, но когда тебе нужно добавить ровно один метод - наследоваться жутко впадлу
Для меня в своей практике нужда добавить метод в интерфейс это повод задать себе вопрос - все ли так с моей архитектурой, или пора рефакторить. Своего рода индикатор - очень помогает.
RK
А если это стандартный интерфейс?
SK
А если это стандартный интерфейс?
Их я использую осторожно.
RK
Или интерфейс сторонней либы?
SK
Или интерфейс сторонней либы?
Ответ тот же
RK
Мне например недавно понадобилась либа, умеющая в портграфы. В Scala я бы недолго думая взял JGraphT и примешал к конкретному классу графа нужные мне вещи. А так пришлось велосипедить
SK
Мне например недавно понадобилась либа, умеющая в портграфы. В Scala я бы недолго думая взял JGraphT и примешал к конкретному классу графа нужные мне вещи. А так пришлось велосипедить
Не могу сказать как бы я поступил на твоем месте. Для меня jgrapht это конкретика, одно из возможных решений гипотетической бизнес-задачи. Постановка бизнес-задачи = дизайн интерфейсов. Какая была бизнес-задача?
RK
Построить и провалидировать множество портграфов
RK
Т.е. граф, вершины которого имеют входящие и исходящие порты
SK
Т.е. граф, вершины которого имеют входящие и исходящие порты
На графах я уже один раз огреб из-за хренового знания матчасти, но попробую. Из бизнес задачи видны следующие интерфейсы:
interface Graph {
/// методы для доступа к полям и ребрам. Имплементаций может быть несколько в зависимости от внутреннего способа представления графа
}
Какой нибудь наследник от Predicate, принимающий граф и отвечающий - валидный он или нет.
interface Graph {
/// методы для доступа к полям и ребрам. Имплементаций может быть несколько в зависимости от внутреннего способа представления графа
}
Какой нибудь наследник от Predicate, принимающий граф и отвечающий - валидный он или нет.
SK
Вне зависимости от того какой граф и как мы валидируем, если интерфейсы спроектированы верно, они не будут меняться.
SK
И не будет нужды ничего никуда подмешивать. Интерфейс Graph уже будет в себе содержать все необходимое для reasoningа на графе.
SK
Но опять же это - не энтерпрайс, не то. Граф он и завтра будет графом. Веселее когда есть бизнес и его постоянно меняющиеся требования.
SS
Насчёт расширяемости, помню как в одном проекте, где мы с @max_belov вместе работали, в деплоймент можно было подложить джарник с любыми классами в специальную папку, и они загрузятся в первую очередь. Очень удобно было фиксы тестить.
MB
Насчёт расширяемости, помню как в одном проекте, где мы с @max_belov вместе работали, в деплоймент можно было подложить джарник с любыми классами в специальную папку, и они загрузятся в первую очередь. Очень удобно было фиксы тестить.
delta_mcp.jar? У меня сейчас скупая мужская слеза ностальгии скатилась просто 😅