Чем структура данных для репутации управляет в C# (как Переполнение стека)
Я в настоящее время создаю систему, которая будет иметь объекты, которые будут иметь очки как репутация и т.д.
У меня будет сервис, который проверит на определенные правила, инициированные, и выполнит определенную логику, если они будут инициированы.
Ранее я использовал, говорят, что Перечисление для того, чтобы сделать это, когда я должен был только сохранить идентификатор и описание.
public enum ShoppingCratCalculation
{
PartialCalculation = 1,
CompleteCalculation =2
}
Но в этой ситуации я хочу хранить больше информации, такой как модификация к репутации, всем в одном месте.
Я по существу спрашиваю, какая структура данных подошла бы лучше всего для того, чтобы хранить эту информацию для каждого правила в системе.
1. Description = string ("User forgot to write a review")
2. DB id = int (23)
3. Rep score modification = int (-5)
Возможно, немного класса (Rule) с ними как свойства, и затем просто a list<Rule>?
У кого-либо есть какие-либо предложения лучшей практики для этого вида структуры?
2 ответа
Я бы, вероятно, использовал класс для хранения данных правила, но структура данных, которую вы используете для их хранения, действительно зависит от того, как организованы ваши правила. Вы говорите, что это похоже на SO, но SO обычно отображает действия на репутацию. В вашем примере это звучит так, как если бы вы отображали качества действия на репутацию. В этом случае использование такой же системы может быть неуместным. Например, вам действительно нужна возможность отрицательного подсчета очков - SO это разрешает, но, возможно, вы этого не делаете. В конце концов, похоже, ваша цель - продавать вещи - вы можете подумать о том, как дадут человеку негативную репутацию за то, что он что-то покупает.
Сказав это, я хотел бы рассмотреть несколько вещей. Если структура плоская и в любой момент времени может применяться только одно правило или каждое правило является независимым, тогда может быть уместен Словарь с ключом по идентификатору правила (возможно, перечисление). Если может применяться более одного правила и они взаимодействуют, возможно, вы захотите сохранить их в коллекции и создать составное правило, используя шаблон Decorator из всех соответствующих правил. Например, покупка с аутентифицированной учетной записью и написание отзыва может дать вам больше репутации, чем написание обзора с анонимной учетной записью.Если правила иерархические, т. Е. Есть некоторый приоритет, то цепочка фильтров с возможностью прерывания цепочки может быть более подходящей.
Вы можете хочу взглянуть на некоторые производственные системы . Они позволяют обрабатывать правила и реагировать на действия, выполняя определенные действия.