[Gnumed-devel] re: messy code

[syan tan]

I had a look it , after a break learning something else for fun, and I 
agree, it does look a bit messy, especially when
the reasons for doing things aren't justified explicitly.

These were the structural ideas I was following:

Each unit of data has it's own CRUD business object ( create update 
delete , possibly find)
: a coarse grained unit is ClinicalRecord, and a finer grained unit is 
PastHistory, Allergy, Medications etc...
The finer grained unit was chosen , since it would tend to follow the 
table clin_root_item subclasses.

Each business object for a specific type, has an unvarying CRUD 
interface, but over time, the actual
processing done may change. Separate parts that are going to change more 
quickly from the parts that
aren't going to change as much.
The core tables in gmclinical were regarded as a more slowly changing 
part, vs  extra tables to store extra
field data specific to edit areas, which might change more quickly.
I started off here using the multiple implementations for one interface 
idea,  as used in Decorator and Proxy patterns, and
had a second class mimic the inteface of gmPastHistory. I was going to 
get the gmPastHistoryEditAreaFacade to forward
calls to gmPastHistory, but then I came across the idea that updates 
should be all or none , with regards to one
transaction, so  I thought updating the extra fields for the editarea 
for the past history object  was in the same transaction
as updating clin_past_history.   So then I separated  
create_past_history in gmPastHistory into a transaction managing part
and a backend updating part, and called the latter _create_past_history. 
Then I got  gmPastHistoryEditAreaFacade to
have it's own _create_past_history, but also have a transaction managing 
part create_past_history, which called both it's
own _create_past_history and the gmPastHistory's _create_past_history ( 
which is the backend updating for the core clin_history table).

That way, both core and peripheral updates were within one transaction,
but
with the subsequent tradeoff  that  the thing looks like
a mess , and no one can understand I tried to start of with the 
Decorator Pattern !

Well, mea culpa, and someone please step up to write the coding 
guidelines !! 
(e.g. You could say - NO PARTITIONING , keep all updates whether 
extraneous/temporary or not , within one update method
for one entity ).