c++ - Flexible and Non frustrating parameter passing for Request processing system -

preface problem have run surprisingly , must admit there many ways solve can think of, way using variadic function (bye bye type safety), using hash map (more type issues , feels overkill) or condemning users of class repetitive menial tasks getting system work. turning community try , find way this, doesn't hurt soul.

the problem use request processor example of paradigm, can see how same may apply other non request processing systems or slight mutations of request processing systems.

say have request processor looks :

http://pastebin.com/xriga8u3

there multiple instances of request processor (for reasons) , each of them, comments point out, can have own defaultserializedconfiguration.

the method

unsigned int processrequest(const float nonserializedrequestconfigparam,const requestconfiguration* requestconfig = 0); 

however accepts "requestconfiguration*" parameter in case particular request needs tweaked params, in general however, instances of request processor use "defaultserializedconfiguration".

whenever tweaked requests sent though, 1 or 2 of params tweaked. rest same "defaultserializedconfiguration" values. herein, comes problem, whenever send tweaked request, need construct valid "requestconfiguration*" , fill in all values. key word there, because, perspective of using class, every time want change 1 request processing param, need first of default params copy on values not changing "as is" proceed edit 1 param want edit , call method.

---

sidenote: problem compounded in actual system have contrived example. there no easy way "defaultserializedconfiguration" requestprocessor. (how interact thing call process() method ask ? done using messaging system , there complexities involved add more irrelevant fluff question)

---

so now, left annoying api frustrating , assbackwards user perspective. i.e. thing knows default values, don't want care are, know want mess 1 value, every time want mess 1 value, must others , muck too, can call through.

solutions considered

the simplest solution break open "requestconfiguration" , change function signature of processrequest explicitly accept pointers individual config params, looks :

unsigned int processrequest(const float nonserializedrequestconfigparam,          const float* requestparam1 = 0, const std::string* requestparam2 = 0, const unsigned int* requestparam3 = 0); 

i take multiple issues this, ugly ass long function signature aside, signature not conducive request params changing, every time new requestparam added must added function signature , villagers come @ me pitchforks.

another solution may use variadic function. dislike them because of type safety concerns , still don't solve problem without having weird , complex call. example, if arg[0] requestparam1 , arg[1] requestparam2 , on. every time want mess requestparam3, still have fill in arg[0] , arg[1] , arg[2], leading same issue. or provide format , once again have shitty way people interact system (i.e. knowing weird formats make request , pass few params)

finally, 1 can use hashedmap , key , value both strings , depending on whatever entries made map 1 can loop on convert value string requisite type. since using key know kind of value contained in record.

this method @ face value seems ok, fact 1 has resort constructing hash map every time make request system seems kinda stupid. there cost incurred creating map, passing around can done reference since processrequest method works synchronously , once again ugly api problem of having create map should be, in essence simple hell. also, if think it, method is, in essence same variadic function. format no longer 1 string multiple strings describe data coming in.

disclaimer

i realize question perhaps bit long , drawn out stackoverflow tastes, trust community of people here know atleast 1 non soul crushing way this.

also, example code request processor highly contrived, may tempted ask questions "why need multiple instances of request processor ?" looks stateless should configure every request comes in"

trust me things if could, cant, code embedded. not request processing system , have state info independent of "requestconfigurationparams" yeah, architectural changes no go.

finally, name of question stupid, couldn't think of better 1 can think of better 1 should suggest same.

provide a

const requestconfiguration& getdefaultconfiguration() const 

so user can create configuration existing configuration. (look @ prototype_pattern)