5

I'm programming a process in which clients will be separated in 3 different groups, and for every group a different action will be performed.

My question concerns the process of deciding which client will be in which group.

As input I received a flow diagram with 7 decision blocks.

I think you can imagine the flow chart:

If A and B and Not C and F then you are in group 1.

If A and not B and C and E you are in group B. If A and not B and C and not E but F you also are in group B.

Anyway, you probably get what I mean.

What I'm searching for is what is a good way to implement this?

We've come up with the following solutions

1 program the code like I've typed it: 

if A() && !B() && C() || (D() && E()) groupA.Add(client)
if A() && !B() && C() && F()) groupB.Add(client)

2 program a BIG if / if / else 

if A()
    if B()

    else
        if ! C()

        else
else
    if C()

    else

etc.

But.... both don't make me happy, so I was wondering if there was a better way of solving this?

Michel
  • 971
  • 1
  • 7
  • 17
  • After some more discussion we also thought of putting all the code from the `A()`, `B()` etc methods in separate (`A`, `B` etc.) classes and make a kind of filter classes in a way that all classes would have and perform it's own filtering on the main client list, but that doesn't seem possible because class `A` can't decide that a client must be in group 1 and another in group 2, only the combination of one or more classes can decide that, so there must always be some 'chef/head/controller/orchestration' class in our opinion. – Michel May 28 '15 at 20:07

1 Answers1

3

There are definitely solutions out there which attempt to model flow charts in a generic way.

Things like windows workflow foundation, SSIS, routing in message queues etc.

But in my experience, unless the requirement comes from a technical source. ie IP routing, fail over dns etc where a technical spec for the form of the logic exists. Its best to make your code match the requirement document as closely to the way it describes the logic as possible

You will have holes in the logic and results that seem inconsistent, but your code will meet the requirement, and when the requirement changes in some weird way, you wont find yourself shoehorning it into a clever generic system which expects the logic to be expressed in a particular way.

This usually boils down to a big if block. but it will be easy to read and easy to change

Update: here's ways I've done it/seen it done in the past and regretted it

  • OOP approach, persist logic objects in XML doc, data in another, with elements like <addPercentage conditional="xpath refernce to data doc" value="10">

the xpath soon got super complicated with custom expressions, users never bothered to use the interface, so devs get requests to change logic anyway.

  • eval vb script stored in db

users cant do vb script, working out how a decision was made, next to impossible.

  • eval SQL (because we know that)

users can't do sql either, same probs as with vb script

  • websphere java orchestration with wcf services (because the consultants will setup a 'domain language'

users can't do java/'domain language' once the consultants leave. Hire new team of java devs, deployment/source control issues with web based IDE

  • lisp interpreter. OMG No.

  • windows workflow foundation

out of date even when we used it, over complicated for small tasks. difficult to explain to users

  • SSIS/DTS packages because they have a drag and drop interface!

hacky tool for non programming db admins, version control, deployment, debugging, performance difficulties. not scalable.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • I definately agree with 'it will be easy to read and easy to change'. But nowadays it seems almost like a crime to put more than one 'if' in a method. – Michel May 28 '15 at 20:01
  • Also the code seems so 'procedural', which also seems to be a bad habit. – Michel May 28 '15 at 20:02
  • All the patterns-, TDD-, unit test etc. books never seem to cover these kind of problems imho, and I can't relate this 'big if block' to the clean `Calculator.Add()` clean code.... – Michel May 28 '15 at 20:03
  • No I wouldn't recommend it for 'normal' things, just where you have been told the exact logic rather than the required results, or have some logic which needs to be defined by users. if you see what i mean – Ewan May 29 '15 at 09:36
  • 1
    I _really_ like your update. It provides me with a lot of info why other methods (which we might think of) are not the best idea. – Michel May 29 '15 at 10:34