design patterns - Customer specific requirements in code base -

how handle , best practices out there when implementing small customer specific changes in code base?

this particular product used 10-20 customers , delivered web application. find hard manage , not clutter code when 1 customer want specific feature other customers don't want or haven't bought.

i have looked @ earlier code solves problem if-statements:

if(customerid == customer.one) {  // code goes here... } 

or

if(customer.hasthisspecificfeature()) {  // code goes here.  } 

the problem it's hard maintain when having more few specific features. code unreadable , hard debug.

is there , clean way solve this?

_{further reading: strategy pattern; template method pattern; inversion of control (ioc).}

one way of doing extracting logic has listen customer specific feature , inject implementation instead of baking code. example, use interface:

public int getage(person p) {     return p.age; } 

a customer wants lie ages, asks add 1 ages:

public int getage(person p) {     var age = p.age;      // imagine exists...     if (customercontext.currentcustomer == customer.one)     {         age++;     }      return age; } 

the idea extract post processing of age:

public int getage(person p, iagepostprocessor ageprocessor) {     var age = p.age;     return ageprocessor.process(age); }  public interface iagepostprocessor {     int process(int age); } 

then outside of can decide configure strategies once @ start when know customer context in.

for 1 customer, provide implementation +1s age, else provide pass-through implementation nothing.

you can utilise other di/ioc frameworks (ninject, castle windsor, structuremap) plumbing stuff.

---

alternatively, "interface" func<int, int>:

public int getage(person p, func<int, int> postprocessage) {      if (postprocessage == null)         postprocessage = => a; // nothing.      return postprocessage(p.age); } 

this again moves dependency outside of method , allows make decision on logic elsewhere, perhaps centralised once @ start up.

---

benefit approaches can test customer-specific implementations independently of used prove acceptance criteria met each client.