Множественные ветвления и шаблон «Правила»

Спасибо за статью, весьма интересно!
После прочтения сразу приходит на ум шаблон «Стратегия», и не могли бы вы обозначить нюансы использования описанного шаблона в сравнении со статегией с вашей точки зрения?

Можно более подробно о пункте «О чем нужно помнить?»

Позвольте мне спросить: что имеется ввиду «Знаем, что есть готовые «движковые» решения для бизнес-логики»? Какие, например? Можно ссылочкой :) Спасибо.

> [3,4,5,3,3] — 350 очков

Как получили? Если допустить переупорядочивание, тогда понятно:

[3,3,3,*,*] +300
[5,*,*,*,*] +50

Единственное, что нужно учесть — при реализации этого шаблона может качественно возрасти вычислительная сложность. В подавляющем большинстве случаев оно не сыграет, но тем, кто делает какие-то рефлексивные штуки или с большим количеством переборов самих по себе или с совсем сложной логикой, когда правил много и они рекурсивно зависят друг от друга — можно поймать «плюху». Экспертные системы отличаются от такой простенькой реализации в том числе тем, что позволяют сильно снизить вычислительную сложность в подобных случаях.

А какая действительная польза этого паттерна кроме украшения кода? Сложность алгоритма ведь только возрастёт, а это печально, т.к. подобные проблемы возникают именно там где и так сложность алгоритма не маленькая…

Я бы еще явно определил порядок применения правил. В вашем коде порядок «по максимуму очков добавленных от применения очередного правила к оставшимся костям», и я бы упростил его до «первыми применяются правила приносящие большее кол-во очков» и задал его так:

List<Rule> rules = ...
Collections.sort(rules, sortByScoreDescending);

Но часто встречается другой порядок: «В любом порядке, главное получить наибольшее количество очков»:
Правила:
111xx — 300
11xxx — 200
221xx — 200
Вход:
11122. Ваша реализация посчитает 300 очков, но возможен вариант с 400 очками.

List<Rule> rules = ...

for(List<Rule> orderedRules : perestanovka(rules)) {
  // Посчитать для каждого варианта применения правил и выбрать вариант с самым большим score.
}

А может оказаться, что игроку разрешается выбирать из возможных вариантов. Тогда придется интерфейс этой части системы менять.

Повторюсь, я бы еще явно задал порядок применения правил.

Эта логика не даст максимальный результат если одна единица будет давать 100 очков, а три единицы 200. Тогда при выпадении трёх единиц будет получено 200 очков, а если учитывать их по одной, то можно зачислить 300 очков

Извините, но это ужасно. Визуально, тот код, который назывался плохим для игры в кости, выглядит лучше. Он меньше.
Да, он непонятный, но только потому, что совершенно безобразно написаны имена, тройка прыгает по коду.
Если его причесать и если класс действительно должен считать кубики и там написан минимум на данный момент (YAGNI), то он будет лучше. Но он правда и ягни не отвечает. Просто странно ни в какие ворота написан.

Паттерн здесь выглядит еще хуже.
Сразу оговорюсь, я не критикую автора вообще за паттерн, возможно он хотел показать его использование, а пример выбрал неудачный.

Но я лично, паттерны и не люблю. Паттерны появляться должны самостоятельно, если надо. Обычно, они нужны для гибкости. Но программы не должны быть гибкими. Программы должны быть точными. А это буквально наоборот, чем то, что здесь написано. Т.е. вы с чего-то думаете о каком-то вымышленном завтра, когда вдруг внезапно появятся новые правила. И наворотили бог весть что. Вывернули логику, заставили страдать компилятор.

Не воспринимайте как оскорбление, просто давайте по другому взглянем на задачу. Я всегда говорил, что язык программирования — это язык, а программирование — это перевод требований. Как есть. Без никаких домыслов о завтра. Завтра будет завтра. Если записано как есть, то и менять не очень много надо будет. Также, в коде должно быть максимальное соотношение кода, которое прямо относится к задаче и к требованиям. Их должно быть видно.

Давайте и посмотрим:

1 X X X X — 100 очков
5 X X X X — 50 очков
1 1 1 X X — 1000 очков
2 2 2 X X — 200 очков
3 3 3 X X — 300 очков
4 4 4 X X — 400 очков
5 5 5 X X — 500 очков
6 6 6 X X — 600 очков

Это буквально юз-кейсы. Какие требования?
1. Порядок не важен.
2. Из всех комбинаций ищем наборы комбинаций (назову шаблонов), которые дают максимальное количество очков.
И вот код:

int GetScore(int[] roles)
{
    List<int> rolesList = roles.ToList();

    Func<int> getScoreFromBestTemplate = () =>
        {
            var templatesWithScores = new []
                {
                    new { Template = new List<int> {1}, Score = 100 },
                    new { Template = new List<int> {5}, Score = 50 },
                    new { Template = new List<int> {1, 1, 1}, Score = 1000 },
                    new { Template = new List<int> {2, 2, 2}, Score = 200 },
                    new { Template = new List<int> {3, 3, 3}, Score = 300 },
                    new { Template = new List<int> {4, 4, 4}, Score = 400 },
                    new { Template = new List<int> {5, 5, 5}, Score = 500 },
                    new { Template = new List<int> {6, 6, 6}, Score = 500 },
                };

            Func<List<int>, List<int>, List<int>> deleteMatchElements = (source, template) =>
                {
                    var sourceCopy = source.ToList();
                    template.ForEach(item => sourceCopy.Remove(item));
                    return sourceCopy;
                };

            Func<List<int>, List<int>, bool> isMatch =
                 (source, template) => deleteMatchElements(source, template).Count == source.Count - template.Count;

            var templateWithMaxScore = 
                (from tws in templatesWithScores
                    where isMatch(rolesList, tws.Template)
                    orderby tws.Score descending
                            select tws
                            ).FirstOrDefault() ?? new { Template = new List<int> {}, Score = 0 };

            rolesList = deleteMatchElements(rolesList, templateWithMaxScore.Template);

            return templateWithMaxScore.Score;                    
        };

    int sumScore = 0;
    int score = 0;
    do
    {
        score = getScoreFromBestTemplate();
        sumScore += score;
    }
    while (score != 0);

    return sumScore;
}

Согласитесь, так читаемость намного лучше. Требования видны невооруженным глазом. Не надо разбираться с конструкторами классов. Да и классы писать не надо. Буквально видно по шагам, как откуда всё получается. Не должно быть у простых задач много кода!
В нем да, жестко зашиты требования, как поняты мною на данный момент. Да, в этом коде заложено, что я выбираю всегда самый «дорогой» шаблон. Но ведь так и надо на данный момент. Именно это и требуется из задачи. Нет никакого будущего. Если меня попросили перевести на английский «собачка перебежала дорогу», то именно так и надо поступать, а не писать «ххх перебежало дорогу». Чтобы когда-то послезавтра кошку туда подставить. Когда требования выражены четко, когда кода минимум, тогда и переписать будет не проблема, если изменятся требования.

Код возможно не идеально простой. Может, заставит задуматься о замыканиях и сайд-эффекте.
Но, в общем, не в паттернах счастье.

удалено