AZ
короче
Size: a a a
2020 February 25
AZ
когда у тебя логика начинает вонять инфрастуктурой (а вывод на экран это именно она), то значит надо что-то пересмотреть
P
может я за фича гейтом хочу реализовывать
ну если за фича-гейтом, то логично делать один метод на 100 строк, потому что это как бы отдельная зависимость
P
когда у тебя логика начинает вонять инфрастуктурой (а вывод на экран это именно она), то значит надо что-то пересмотреть
ноуп, для юнитов вывод на экран это прикладная вещь
AZ
ноуп, для юнитов вывод на экран это прикладная вещь
нет
P
если нет, то надо смотреть в сторону апи даты/времени
В
А чем сейчас sloc мерять модно?
B
именно поэтому я за бэ эс дэ
Серьезно на фряхе на десктопе сидишь?
P
Серьезно на фряхе на десктопе сидишь?
на маке сидит небось
NL
лучше 500 строк размазанных по проекту близко к домену, чем 100 строк в одном месте (на самом деле ты утрируешь, там будет порядка 1.2-3 множитель, не 5) тогда удаляя один файл ты удаляешь только его, а когда нужно добавить новый, ты просто копируешь существующий и меняешь соответствующие методы, а не бегаешь по всему проекту в поисках где же он будет использоваться
Кстати, я давненько исследовал вопрос ADT vs Visitor pattern, и у меня есть весьма конкретный код, чтобы оценить удобство:
Задача: написать абстракцию над выражениями, где могут быть константы, переменные и бинарная операция `+` для простоты. Реализовать вычисление и преобразование для упрощения таких выражений.
https://pastebin.com/fcYdQWVX
Написано на Скале, но я думаю разберётесь. Особенно хотелось бы отметить, что визиторовская версия не дописана, потому что явно муторно и сложно:
в то время как ADT-шная версия по-прежнему вполне читаема.
Задача: написать абстракцию над выражениями, где могут быть константы, переменные и бинарная операция `+` для простоты. Реализовать вычисление и преобразование для упрощения таких выражений.
https://pastebin.com/fcYdQWVX
Написано на Скале, но я думаю разберётесь. Особенно хотелось бы отметить, что визиторовская версия не дописана, потому что явно муторно и сложно:
class Simplify extends Op[Tree] {
override def apply(c: TConst): Tree = c
override def apply(v: TVar): Tree = v
override def apply(s: TSum): Tree = {
// TODO implement this
???
}в то время как ADT-шная версия по-прежнему вполне читаема.
NL
Код можно скопипастить и запустить, никаких зависимостей.
P
Кстати, я давненько исследовал вопрос ADT vs Visitor pattern, и у меня есть весьма конкретный код, чтобы оценить удобство:
Задача: написать абстракцию над выражениями, где могут быть константы, переменные и бинарная операция `+` для простоты. Реализовать вычисление и преобразование для упрощения таких выражений.
https://pastebin.com/fcYdQWVX
Написано на Скале, но я думаю разберётесь. Особенно хотелось бы отметить, что визиторовская версия не дописана, потому что явно муторно и сложно:
в то время как ADT-шная версия по-прежнему вполне читаема.
Задача: написать абстракцию над выражениями, где могут быть константы, переменные и бинарная операция `+` для простоты. Реализовать вычисление и преобразование для упрощения таких выражений.
https://pastebin.com/fcYdQWVX
Написано на Скале, но я думаю разберётесь. Особенно хотелось бы отметить, что визиторовская версия не дописана, потому что явно муторно и сложно:
class Simplify extends Op[Tree] {
override def apply(c: TConst): Tree = c
override def apply(v: TVar): Tree = v
override def apply(s: TSum): Tree = {
// TODO implement this
???
}в то время как ADT-шная версия по-прежнему вполне читаема.
у тебя там код, который должен быть в операторе написан в интерпретаторе при том, что у тебя всего по одному интерпретатору каждого вида
P
если б у тебя было несколько разных интерпретаторов, то мб имело бы смысл писать оптимайз для суммы в них
NL
если б у тебя было несколько разных интерпретаторов, то мб имело бы смысл писать оптимайз для суммы в них
Гхм, если бы было несколько разных интерпретаторов (а их уже 4: eval, format, flatten и simplify), то визитор становится уже антипаттерном, а не дизайн паттерном.
P
Гхм, если бы было несколько разных интерпретаторов (а их уже 4: eval, format, flatten и simplify), то визитор становится уже антипаттерном, а не дизайн паттерном.
у тебя это свойства самих операций вынесенные за сами операции
P
если бы у тебя были разные эвалы это имело бы смысл или форматы
NL
у тебя это свойства самих операций вынесенные за сами операции
simplify это свойство Sum? Свежий взгляд на дизайн, ничего не скажешь...Но вообще: talk is cheap, show me the code
P
simplify это свойство Sum? Свежий взгляд на дизайн, ничего не скажешь...Но вообще: talk is cheap, show me the code
simplify это свойство BinaryOperator
NL
simplify это свойство BinaryOperator
по-прежнему свежо и по-новаторски, с удовольствием бы взглянул.