ЕР
atcq (Алексей)
вопрос: а есть ли какой-то измеряемый/доказуемый профит у всего этого упарывания по функциональщине?
Стоимость поддержки
Size: a a a
2020 November 22
a
Стоимость поддержки
ну те. можно смело нанимать функциональщика и он один будет поддерживать проект за двоих, троих?
NF
atcq (Алексей)
вопрос: а есть ли какой-то измеряемый/доказуемый профит у всего этого упарывания по функциональщине?
ну это как ООП +-, различие лишь в том что ты определяешь контексты/классы динамически
ЕР
atcq (Алексей)
ну те. можно смело нанимать функциональщика и он один будет поддерживать проект за двоих, троих?
Я такого не говорил
YG
Фп вообще не понятно что, также как и ооп
NF
ну т.е. если в ООП я думаю заранее какой интерфейс мне нужен и это делает абстракции заранее более стабильными, то с фп подходом я такой: так, для этого модуля order будет из 3 методов, а для вот этого order из 2 совершенно других методов.
И решение о том будет ли эти два order одним классом принимается после написания реализации, а не до.
И решение о том будет ли эти два order одним классом принимается после написания реализации, а не до.
NF
это почти как с tdd, есть какое-то неуловимое сходство
a
ну т.е. если в ООП я думаю заранее какой интерфейс мне нужен и это делает абстракции заранее более стабильными, то с фп подходом я такой: так, для этого модуля order будет из 3 методов, а для вот этого order из 2 совершенно других методов.
И решение о том будет ли эти два order одним классом принимается после написания реализации, а не до.
И решение о том будет ли эти два order одним классом принимается после написания реализации, а не до.
я спрашивал не совсем это, но почитать было интересно, спасибо
a
хотя и в ооп коде interface segregation практически 1 в 1 совпадает с твоим описанием, те. сущность в итоге может быть почти любой, лишь бы удовлетворяла нужному в конкретном месте интерфейсу
NF
atcq (Алексей)
я спрашивал не совсем это, но почитать было интересно, спасибо
ну прям про профит это то что интерфейсы изначально намного меньше, а значит поддерживать проще, не может так случиться что код делает слишком много, но может случиться что он делает слишком мало
NF
к той самой золотой середине solid код подходит с разных сторон
YG
Хз по моему в этом как раз нет отличия фич ооп от фич фп
SP
Хз по моему в этом как раз нет отличия фич ооп от фич фп
Если ооп грамотно применять то да, если как все то уже не так очевидно
YG
Ну вот вики выделяет 4 концепции ФП:
Функции высших порядков
Чистые функции
Рекурсия
Подход к вычислению аргументов
Функции высших порядков
Чистые функции
Рекурсия
Подход к вычислению аргументов
NF
Чтобы написать хороший ооп код нужно либо заранее хорошо подумать, либо после реализации хорошо порефакторить сделав interface segregation с наиболее стабильными абстракциями.
С фп получается что изначально ты пишешь с каким то next level interface segregation, а потом решаешь какие интерфейсы образуют стабильную абстракцию более верхнего уровня.
С фп получается что изначально ты пишешь с каким то next level interface segregation, а потом решаешь какие интерфейсы образуют стабильную абстракцию более верхнего уровня.
NF
вот так наверное более точно, по моим ощущениям от процесса
YG
Чтобы написать хороший ооп код нужно либо заранее хорошо подумать, либо после реализации хорошо порефакторить сделав interface segregation с наиболее стабильными абстракциями.
С фп получается что изначально ты пишешь с каким то next level interface segregation, а потом решаешь какие интерфейсы образуют стабильную абстракцию более верхнего уровня.
С фп получается что изначально ты пишешь с каким то next level interface segregation, а потом решаешь какие интерфейсы образуют стабильную абстракцию более верхнего уровня.
Те с ооп ты сначала закидывал все зависимости в импорт? А потом уже решал нужно что-то или нет?
У меня скорее больше итеративный процесс нахождения более точных границ модулей
У меня скорее больше итеративный процесс нахождения более точных границ модулей
SP
Ну вот вики выделяет 4 концепции ФП:
Функции высших порядков
Чистые функции
Рекурсия
Подход к вычислению аргументов
Функции высших порядков
Чистые функции
Рекурсия
Подход к вычислению аргументов
А потом читаем про functional core imperative shell
SP
Это и с ооп хорошо работает в общем то
YG
А потом читаем про functional core imperative shell
Ну я на джаве примерное так и пишу)