From: Andy O'Neill on
I am designing a system which will work in a totally different way to any
I've designed before.
Almost everything has to be configurable.
The user will be picking things from lists into a basket.
The things have a set of dependency rules.
So you must pick at least so many of one classification.
You may pick no more than so many of another.
You need n of a particular thing per 1 of another.
Unless you pick this special thing which alters how common something else
is.
Then of course they can remove something from their basket.
If that happens to be the special thing that alters rules, then the rules
applied need to revert and give a warning if things in the basket break the
rules.
Things often have a number of options ( optional upgrades ) which may be
chosen and in turn are fairly complex.
EG a given upgrade may only be attached to one thing in the basket.

All these rules need to be configurable via xml or xaml or something.
Even the attributes of each thing will be variable.
It'll be a WPF application with no database - xml will be used to store user
input instead.

Whilst the rules can be quite complex there aren't a huge number of things
go into the basket.

I was wondering if anyone has done anything similar and has any thoughts,
can recommend a pattern... example or whatever.
Thanks in advance.


From: Tom Shelton on
On 2010-01-04, Andy O'Neill <aon14nocannedmeat(a)lycos.co.uk> wrote:
> I am designing a system which will work in a totally different way to any
> I've designed before.
> Almost everything has to be configurable.
> The user will be picking things from lists into a basket.
> The things have a set of dependency rules.
> So you must pick at least so many of one classification.
> You may pick no more than so many of another.
> You need n of a particular thing per 1 of another.
> Unless you pick this special thing which alters how common something else
> is.
> Then of course they can remove something from their basket.
> If that happens to be the special thing that alters rules, then the rules
> applied need to revert and give a warning if things in the basket break the
> rules.
> Things often have a number of options ( optional upgrades ) which may be
> chosen and in turn are fairly complex.
> EG a given upgrade may only be attached to one thing in the basket.
>
> All these rules need to be configurable via xml or xaml or something.
> Even the attributes of each thing will be variable.
> It'll be a WPF application with no database - xml will be used to store user
> input instead.
>
> Whilst the rules can be quite complex there aren't a huge number of things
> go into the basket.
>
> I was wondering if anyone has done anything similar and has any thoughts,
> can recommend a pattern... example or whatever.
> Thanks in advance.

The only advice I have is to take a look at Windows Workflows. There is a
built in rules engine and you can create and alter rules using a dialect of
xaml.

--
Tom Shelton
From: RayLopez99 on
On Jan 4, 10:17 am, "Andy O'Neill" <aon14nocannedm...(a)lycos.co.uk>
wrote:
> I am designing a system which will work in a totally different way to any
> I've designed before.
> Almost everything has to be configurable.

Just use enums and make sure they are a power of two. That way you can
XOR them. It's in any standard textbook.

RL
From: Andy O'Neill on
"RayLopez99" <raylopez88(a)gmail.com> wrote in message
news:059ff5c5-fab2-4973-baaf-568ab709f880(a)k17g2000yqh.googlegroups.com...
On Jan 4, 10:17 am, "Andy O'Neill" <aon14nocannedm...(a)lycos.co.uk>
wrote:
> I am designing a system which will work in a totally different way to any
> I've designed before.
> Almost everything has to be configurable.

Just use enums and make sure they are a power of two. That way you can
XOR them. It's in any standard textbook.

RL


By configurable, I mean in separate user maintainable file(s) rather than
code.

Enums have to be written at compile time.
It will be a generic tool.
At the time I write the programme I won't know what to enumerate, let alone
what values mean what and what rules to apply.






From: Gregory A. Beamer on
"Andy O'Neill" <aon14nocannedmeat(a)lycos.co.uk> wrote in
news:EEn0n.36533$Ic5.30388(a)newsfe16.ams2:

> I was wondering if anyone has done anything similar and has any
> thoughts, can recommend a pattern... example or whatever.

I like the workflow option and would advise at least looking it over. It
might not work for you, but it will greatly reduce the amount of
plumbing you need to write.

If that is not an option, the direction you head depends on what the
items on the list are. If primarily behaviors, then I see a couple of
patterns coming to mind:

1. Decorator - to add "rules" into the workflow
2. Strategy - to better switch out algorithms

This is a very high level look and I understand too little about your
project to be more specific.

Another possible pattern is the chain of repsonsibility, if you can
easily chain the workflow together

If you are heading with state, decorator is likely to still be involved.

Just some thoughts off the top of my head.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************