SP
к тому же в фп и правда много маняфантазий. я прям чувствую как мне вскружило голову вера в то что можно делать все иначе и без страданий
Size: a a a
2020 February 25
P
ну как бы нельзя просто ругать фп исходя из позиций сложна сложна. находятся люди которые таки разбираются в фп и критикуют уже с позиции разочаровавшихся вот павел играет роль такого разочаровавшегося в фп опепешника
я не разочарован в фп, просто я считаю, что ооп -- более конкретное фп и на ооп языках есть то же самое фп, только для него разные варианты отдельных фпшных абстракций в зависимости от назначения и вот эта дополнительная конкретизация облегчает восприятие кода
P
тоесть фп удобно для рассуждений, рефакторинга, моделирования, но понимать проще ооп код, если ты видишь его в первый раз
SP
... а я как и всегда не понимаю какой смысл вкладывают в ооп
P
ну лучше 100 строк чем 500, нет?
лучше 500 строк размазанных по проекту близко к домену, чем 100 строк в одном месте (на самом деле ты утрируешь, там будет порядка 1.2-3 множитель, не 5) тогда удаляя один файл ты удаляешь только его, а когда нужно добавить новый, ты просто копируешь существующий и меняешь соответствующие методы, а не бегаешь по всему проекту в поисках где же он будет использоваться
В
потому, что ты делаешь наоборот
А как надо?
P
А как надо?
просить сам тип Unit быть Display
AZ
лучше 500 строк размазанных по проекту близко к домену, чем 100 строк в одном месте (на самом деле ты утрируешь, там будет порядка 1.2-3 множитель, не 5) тогда удаляя один файл ты удаляешь только его, а когда нужно добавить новый, ты просто копируешь существующий и меняешь соответствующие методы, а не бегаешь по всему проекту в поисках где же он будет использоваться
для простых кейсов из разряда "20 веток по 5 строк" множитель порядка х5 мне кажется более реалистичным
P
а не навешивать его сверху
P
для простых кейсов из разряда "20 веток по 5 строк" множитель порядка х5 мне кажется более реалистичным
по 5 строк это как раз будет меньше х3
В
просить сам тип Unit быть Display
Так если я запрошу тип
Unit быть Display, мне придётся его [display] реализовать... точно так-же как и сейчасAZ
по 5 строк это как раз будет меньше х3
это обявление класса, объявление метода, конструктор обязательно... Это всё 25 строк легко займет
AZ
просить сам тип Unit быть Display
слишком сильное ограничение, может я хочу юнит без дисплея
P
Так если я запрошу тип
Unit быть Display, мне придётся его [display] реализовать... точно так-же как и сейчасда, но у тебя будет отдельно для каждого типа Display реализация, ты открываешь тип и видишь, что он отображается вот так
В
да, но у тебя будет отдельно для каждого типа Display реализация, ты открываешь тип и видишь, что он отображается вот так
Нету отдельных типов. Тип один —
struct Unit<...>AZ
а вообще это решается по идее тем что варианты энумов можно делать отдельными типами
P
слишком сильное ограничение, может я хочу юнит без дисплея
у всех юнитов есть дисплей, юниты пришли из письма
AZ
у всех юнитов есть дисплей, юниты пришли из письма
счего бы у них у всех был дисплей?
P
счего бы у них у всех был дисплей?
вторая часть предложения
AZ
может я за фича гейтом хочу реализовывать