java - Designing how much to abstract a setter/modifier -
my application receives xml messages update it's data objects. xml message contains details on how data modified. xml looks like:
<data> <stuff> .... </stuff> <stuff> .... </stuff> <objs> <obj attr1=... attr2=... /> <obj attr1=... attr2=... /> </objs> </data> how should update fields of objects?
create modify(string xml) method. parse message, extract
<stuff>data, reconstruct following<obj attr1=... />string , pass modify().create modify(namednodemap xml) method. parse message, extract
<stuff>data, keep results of parsing (document object), find relevant node , pass modify().create modify(string attr1, string attr2, ...) method. parse xml, extract fields, pass modify(). bad idea, because if need more attributes, need change method signature, , breaks depend on modify() method.
create setters every field. parse xml, set fields individually. run whole getter , setter debate, , in context of application, fields of data objects should modified these xml messages, not anywhere else.
personally i'm torn between 1 , 2. think 1 more flexible, in case decided not use dom, can change how string parsed inside modify(string xml) method. have parse xml twice, once obtain <stuff> data, reconstructing xml string, , being parsed again inside modify() method.
should xml parsing done inside data classes? there reason choose other choices? thanks.
[edit] in general, how should "unpack" data before passing method?
i'd suggest option 4, because don't want data objects closely tied message transport mechanism.
with options 1 , 2 if decide change xml schema (or if decide xml verbose, or if want include encryption etc etc) have change data object implementation - same reason option 3 bad.
are absolutely current set of xml messages reason data change, ever? mean really absolutely 100% no-one ever not want use xml? if not, go 4. decoupling implementation (data object) interface (xml messages) best way ensure code maintainable.
Comments
Post a Comment