Да, согласен, хотя это немного другой вопрос — разбиение приложения на функции. Конечно, нужна какая-то итеративность тест-код-тест-код, невозможно заранее написать тесты для большого куска приложения.
В примере с number_of_german_letters нужно считать функцию is_german_letter частью ее интерфейса. Т.е. это функция высшего порядка с двумя аргументами: функцией определения буквы и строкой. Интерфейс будет что-то типа
number_of_specific_letters (is_specific_letter, s)
а вызывать ее будем как
number_of_specific_letters (is_german_letter, «abc1»)
Тогда можно рассматривать ее как черный ящик?
В какой-то степени это напоминает статус коды в стиле С… История движется по спирали.
Исключения тоже не на ровном месте появились. В частности, если мой метод не знает, что делать с ошибкой, он должен передать ошибку на уровень выше. При исключениях я не должен делать ничего. При «результатах» я должен не забыть их правильно скомбинировать и пробросить наверх. И таких пробросов может наслоиться несколько уровней. И не забудьте тестами все это покрыть…
Maybe вполне можно использовать и без Fody, с сочетанием соглашения не возвращать null и ручных проверок.
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».
Не знаком с ними, но
1. Думаю, потратили на них значительно больше времени.
2. В румах против людей они не побьют вообще ничего. Тем более, гугл говорит они 2006 года.
Я так понимаю, это теоретический комментарий? Попробуйте на досуге составить
«Si is a finite set of actions or choices for player i
A = S1 ×... × Sn is the set of all possible combination of simultaneous actions of all players»
для безлимитного текасского покера.
Готов сыграть против вашего бота (я менее чем средненький игрок).
Невозможно за 6 часов написать бота, который хоть как-то сгодится против человека, даже если тот тоже сел играть в первый раз 6 часов назад.
Бот, успешно играющий против регуляров покер-румов — это человеко-годы нетривиальной работы. Особенно в безлимитные разновидности покера. Ну, может человеко-месяцы для низших лимитов. Плавали, знаем.
Я тоже стал думать в эту сторону. Автор начинает с того, что предлагает задуматься над причиной принятия наших решений, а потом без всяких раздумий выбирает ООП как концепцию.
В то же время, существует (и поддерживается многими) мнение, что ООП-моделирование в классическом понимании красиво в теории, но создает огромное количество проблем на практике. А также существуют другие подходы, такие как функциональное программирование, пытающиеся преодолеть эти ограничения.
Понятно, что с таким разбором статья получилась бы совсем большой. Но стоило хотя бы отметить существование выбора.
Т.е. по всем трем методикам выходит, что разработка на C в 3-7 раз проще, чем разработка на C#.
Вы согласны с этим тезисом или как можете объяснить это соотношение?
Популярная в наше время мотивация: «Да, наш закон ужасен, но вообще это нормальная практика во всех странах, а кое где еще хуже. Так давайте будет патриотами!»
При этом мы работаем во всех странах Европы (и не только), а сервера надо переносить только в РФ.
Про Германию вы преувеличиваете, про США вообще вода. Ох уж эти сказочники…
Если новый тип не требует специального поведения, F# код или реализация «в лоб» (как у lasalas) не изменятся.
Если требует специального поведения — изменится в одном месте, а не 3х связаных классах.
На мой взгляд, показать выразительность языка не очень удалось. На F# с pattern matching получилось бы гораздо выразительные.
Обильное применение паттернов для решения задачи, которую можно было бы решить в несколько строк, свидетельствует скорее о нехватке языковых конструкций.
Плюс нарушение SOLID принципов, дупликация кода…
Возможно, это решение имело больше плюсов в вашей бизнес задаче из реальной жизни.
Спасибо за статью!
Многие тезисы как минимум спорны, стилистика описания разных языков сильно различается, да и еще и пунктуация хромает.
Это в сравнении с каким периодом? Как мог C# вырасти в 2 раза за последний год-два?
number_of_specific_letters (is_specific_letter, s)
а вызывать ее будем как
number_of_specific_letters (is_german_letter, «abc1»)
Тогда можно рассматривать ее как черный ящик?
Исключения тоже не на ровном месте появились. В частности, если мой метод не знает, что делать с ошибкой, он должен передать ошибку на уровень выше. При исключениях я не должен делать ничего. При «результатах» я должен не забыть их правильно скомбинировать и пробросить наверх. И таких пробросов может наслоиться несколько уровней. И не забудьте тестами все это покрыть…
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».
1. Думаю, потратили на них значительно больше времени.
2. В румах против людей они не побьют вообще ничего. Тем более, гугл говорит они 2006 года.
«Si is a finite set of actions or choices for player i
A = S1 ×... × Sn is the set of all possible combination of simultaneous actions of all players»
для безлимитного текасского покера.
Готов сыграть против вашего бота (я менее чем средненький игрок).
Бот, успешно играющий против регуляров покер-румов — это человеко-годы нетривиальной работы. Особенно в безлимитные разновидности покера. Ну, может человеко-месяцы для низших лимитов. Плавали, знаем.
В то же время, существует (и поддерживается многими) мнение, что ООП-моделирование в классическом понимании красиво в теории, но создает огромное количество проблем на практике. А также существуют другие подходы, такие как функциональное программирование, пытающиеся преодолеть эти ограничения.
Понятно, что с таким разбором статья получилась бы совсем большой. Но стоило хотя бы отметить существование выбора.
Люди, знайте меру и умейте слушать.
Вы согласны с этим тезисом или как можете объяснить это соотношение?
При этом мы работаем во всех странах Европы (и не только), а сервера надо переносить только в РФ.
Про Германию вы преувеличиваете, про США вообще вода. Ох уж эти сказочники…
Если требует специального поведения — изменится в одном месте, а не 3х связаных классах.
Обильное применение паттернов для решения задачи, которую можно было бы решить в несколько строк, свидетельствует скорее о нехватке языковых конструкций.
Плюс нарушение SOLID принципов, дупликация кода…
Возможно, это решение имело больше плюсов в вашей бизнес задаче из реальной жизни.
Спасибо за статью!