1

I have the following problem:

  • An user can withdraw money from 2 payment systems (but the number of payment systems can change anytime in the future).
  • If user has a trusted account on either of these payment systems, money is transfered automatically
  • If user enters a new account then he needs to wait until the end of month to be able to transfer money to this account.

Suposse we have payment systems X and Y. There exist all the following information items:

  • We can do auto withdraw X (1 - Yes/0 - No)- column 1.
  • We can do auto withdraw Y (1 - Yes/0 - No) - column 2.
  • We have deficit of X (1 - Yes/0 - No) - column 3.
  • We have deficit of Y (1 - Yes/0 - No) - column 4.
  • User has trusted account of X (1 - Yes/0 - No) - column 5.
  • User has trusted account of Y (1 - Yes/0 - No) - column 6.
  • User can auto-withdraw X (1 - Yes/0 - No) - column 7.
  • User can auto-withdraw Y (1 - Yes/0 - No) - column 8.
  • User can withdraw X in end of month (1 - Yes/0 - No) - column 9.
  • User can withdraw Y in end of month (1 - Yes/0 - No) - column 10.

In table bellow I tried to show all use cases:

Column 1; Column 2; Column 3; Column 4; Column 5; Column 6; Column 7; Column 8; Column 9; Column 10

1; 1; 0; 0; 1; 1; 1; 1; 0; 0

1; 1; 1; 0; 1; 1; 0; 1; 1; 0 

1; 1; 0; 1; 1; 1; 1; 0; 0; 1

1; 1; 1; 0; 1; 0; 1; 0; 0; 1

1; 1; 0; 1; 0; 1; 0; 1; 1; 0

1; 1; 1; 1; 1; 1; 0; 0; 1; 1

0; 0; 0; 0; 1; 1; 0; 0; 1; 1

Please advise how can I avoid a lot of ifs?

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
Dmitro
  • 119
  • 3
  • 4
    [Karnough maps](http://en.wikipedia.org/wiki/Karnaugh_map) – ratchet freak Nov 05 '14 at 16:45
  • 8
    Lots of 'ifs' do not = spaghetti code – bowlturner Nov 05 '14 at 16:58
  • It is pretty unclear what you want to achieve. Do you want to make a decision if the transfer should happen immediately, at the end of the month, or if the transfer should be forbidden? If yes, how do the above conditions map to this decision? – Doc Brown Nov 05 '14 at 17:34
  • 2
    Have you actually tried coding this? As @bowlturner mentioned, having many if-statements does automatically mean "spaghetti code!". If they are arranged logically, and nested ifs are refactored into other procedures, it might not be that bad. Maybe try it first to see... – FrustratedWithFormsDesigner Nov 05 '14 at 18:11
  • 1
    I have an accepted answer to a similar question here: http://programmers.stackexchange.com/questions/205803/how-to-tackle-a-branched-arrow-head-anti-pattern/205814#205814 – Tulains Córdova Nov 05 '14 at 18:25
  • 1
    "Spaghetti code" means a tangle of control flow or state or dependencies, e.g. class A sets global X then calls B which sets Y which calls C which checks X and maybe sets Z and then calls back to class A... You just require a moderately complex boolean expression. – kevin cline Nov 05 '14 at 18:43
  • 1
    It sounds like you have a data problem, not a coding problem. You say the number of systems can change, but you are hard-coding columns for each system. Normalize that and you'll simplify the problem. – GrandmasterB Nov 05 '14 at 19:21
  • 1
    When you start getting to such complex rules, you might want to start looking at a rules engine instead of trying to write your own. –  Nov 05 '14 at 22:15

2 Answers2

4

How a bout a rules mechanism? Define a class(or a struct or whatever) that defines a rule:

class Rule {
    bool weCanDoAutoWithdrawX;
    bool weCanDoAutoWithdrawY;
    bool WeHaveDeficitOfX;
    bool WeHaveDeficitOfY;
    ...
}

Now, create a list of Rules, and fill it with Rule objects that represent the rules you described in the question. When you want to check a transaction, go over that list and check if it matches the rule. If at least one rule does - approve the transaction.

If you are not familiar with OOP you can store the different sets of conditions as strings of concatenated 1s and 0s ("1100111100","1110110110", etc) stored in a string array. Then you can traverse that array. If at least one string matches the actual values - approve the transaction.

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
Idan Arye
  • 12,032
  • 31
  • 40
  • 1
    A rules mechanism is often the first step down the road to the Inner Platform Effect. – whatsisname Nov 05 '14 at 20:25
  • @whatsisname sounds plausible, I would caution anyone using this approach to make sure not to take the second step. –  Nov 05 '14 at 20:55
0

As I don't see any language specified, use 'switch'. -Or if using C, you can make a function that handles each account type, then make a list of function pointers.

typedef void (*Account)(uint32_t aParameter);
static const Account[] = { mondoBurger, goodBurger };

-If using C++, JavaScript or any other OOP language, you could make an object that handles each account type.

The bottom line is: You can use modular code. One "handler" (whether it be a function or an object) for an account. One "handler" for each action type that can be made.

Thus you just install the handlers in a list and hands the list to the processing function.