Здравствуйте, barn_czn, Вы писали: _>- методы Add и Remove неразрывно связаны, как их на отдельные коллбеки разделишь? То что они идут в связке — подчеркивает семантику
Напишите пример кода, который работает с этой семантикой. Не выдуманный, а практически полезный. То есть я передаю вам ICollection, а вы внутри своего кода используете Add и Remove. А вот, скажем, Get или Find при этом — не используете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, barn_czn, Вы писали: _>>- методы Add и Remove неразрывно связаны, как их на отдельные коллбеки разделишь? То что они идут в связке — подчеркивает семантику S>Напишите пример кода, который работает с этой семантикой. Не выдуманный, а практически полезный. То есть я передаю вам ICollection, а вы внутри своего кода используете Add и Remove. А вот, скажем, Get или Find при этом — не используете.
Легко — стек вызова. Add- добавляю аргументы, Remove — удаляю. И хочу для этого использовать именно ICollection. И попробуйте скажите что это "надуманый" пример, я тут же попрошу строгое определение надуманности.
Здравствуйте, barn_czn, Вы писали: _>Легко — стек вызова. Add- добавляю аргументы, Remove — удаляю. И хочу для этого использовать именно ICollection. И попробуйте скажите что это "надуманый" пример, я тут же попрошу строгое определение надуманности.
Ну почему же надуманный — совершенно нормальный пример. Но лучше бы всё же написать пример кода — потому что непонятно, что за код собирается работать с этим стеком. Вы пишете интерпретатор?
Ещё непонятно, зачем вам потребовался именно интерфейс — ведь для стека вызовов достаточно банального односвязного списка. Почему вы захотите туда передавать разные реализации интерфейса ICollection?
Непонятно, почему вы решили, что вам передадут именно стек — ведь придуманный вами ICollection может реализовывать также и очередь (FIFO), и ваш код интерпретатора просто сломается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, varenikAA, Вы писали:
AA>Получается, что функции высшего порядка делают код чище и проще, и интерфейсы тут как бы не особо уже нужны. AA>Достаточно набора функций, при наличии частичного применения и различные декораторы также становятся не нужны
1) Как это будет работать с DI?
2) Сигнатуры функций станут менее читаемые
Кроме этого действительно разницы между функцией и интерфейсом с одним членом-функцией нету. Если предполагается что согласованых функций будет больше одной (добавить+удалить, коллекции, итд), то лучше интерфейс.
Здравствуйте, mrTwister, Вы писали:
T>1) ООП вынуждает привязывать методы к данным, хотя чаще всего в домене эта связь отсутствует.
Ничего подобного ООП не вынуждает. Вынуждают древние книги про ООП типа Гради Буча, идеи из которых до сих пор копипастят во все мурзилки типа "Профессиональная пазработка за 21 день", пишущиеся исключительно чтобы поднять бабла на ньюбах.
При этом в упомянутом шарпе есть такая штука как extension methods, позволяющая убрать синтаксические различия между методами объектов и статическими методами. Так что руки в выборе сделать метод привязанным к стейту или нет полностью развязаны.
T>Реализован будет произвольный из них, смотря какая пятка зачесалась у программиста. Хотя в ФП стиле все однозначно: "НарисуйКартину(холст, кисть)". Нет никаких разночтений.
Ну и? Этот вариант лишает код очень приятного бонуса — discoverability. Что тут хорошего?
T>2) Данные жёстко связаны с методами.
Как только в ФП появляются замыкания, мы получаем ровно такую же связь.
T>3) ООП провоцирует на создание большого количества лишних сущностей.
Здравствуйте, mrTwister, Вы писали:
T>Приватные данные есть не сами по себе, а появляются для конкретной реализации, и появляются они в том месте, где происходит реализация. То есть не приватные данные определяют реализацию, а наоборот.
Попробуй это обосновать.
Вообще, есть очень простой принцип, позволяющий не содавать в ООП бредовые конструкции. Он очень простой — если метод может быть вынесен за пределы класса, он должен быть вынесен за пределы класса. Его применение спасает практически от всех тех ужасов, которые ты расписал.
T>По поводу диспатча — диспатч нужен не типу, а конкретному алгоритму, этот тип использующему. Но при этом задается диспатч в типе.
Только в случае визитора или виртуальных методов. Которые нужны только если язык убогий и не предоставляет нормальных средств типа паттерн матчинга. Дихотомия ФП/ООП тут совершенно ортогональна, просто без специальных средств диспетчеризации ООП язык остается относительно пригодным, а вот ФП язык можно смело выкидывать на помойку.
T>То есть при проектировании типа нам надо иметь ввиду конкретный алгоритм.
Опять же нет. Конкретный алгоритм нужен только в случае использования виртуальных методов. А страшный и ужасный визитор как раз и предназначен для развязки алгоритмов и обрабатываемых.
