[Cosmo-dev] Refactor of cal_main.js

[John Townsend]

On Aug 15, 2006, at 11:08 AM, Matthew Eernisse wrote:

> Brian Moseley wrote:
>> how is extracting the current code into separate files going to  
>> help a
>> future redesign? does chopping up the code like this help you get a
>> better handle on what's there? seems like you have a pretty good idea
>> already.
>>
> That's a good point. The main reasons I initially approached the  
> refactoring this way were:
>
> 1. Breaking up the Cal object into those separate areas of  
> functionality has to happen anyway to accommodate the architectural  
> changes.
> 2. Much of the code will not actually change (e.g., the conflict- 
> resolution code, the position-calc code, etc.)
> 3. It will make it easier to do serious refactoring (with multiple  
> people working, hopefully).
> 4. I am just most comfortable working in an iterative way. It lets  
> me focus on a single change or type of change at a time, and  
> reduces confusion about why something is broken.
>

Your note here makes me immediately think.. We could come up with  
some nice abstractions and interfaces that encapsulate some of the  
items you mention above. For example taking the conflict-resolution  
code out of the main file and refactoring it into a conflict resolver  
abstraction and try to layer its work (i.e. conflict abstraction at  
an abstract or data level followed by an abstraction for rendering  
conflicts. I don't fully know the details of this code, so I might be  
speaking out of turn :-)


> > it looks like you've done a good job of listing all the different
> > responsibilities of the existing code. why don't we sit down and  
> work
> > out how to assign those responsibilities to different classes and  
> map
> > out their collaborations? i think this will address the real need,
> > whereas simply partitioning code into different files won't achieve
> > any real benefit and will just add more import statements.
>
> I'm sure open to other approaches -- I just like to work in an  
> iterative and incremental way, rather than doing a big rewrite up- 
> front. To me part of the benefit of simply breaking the code up is  
> that it gets us closer to the design we want.
>
> But yes, I think a good whiteboard discussion would be really  
> helpful before diving in. There may be changes that it would make  
> sense to implement as I'm in the process that would also get us  
> closer.
>

I agree with BCM. Taking a step back and thinking about the overall  
design would be helpful at this stage. You now have a view of the  
roles and responsibilities within the code and we can take a hard  
look at that view and see if we can come with a way of rendering it  
that is more flexible, extensible, and maintainable. I personally am  
a big fan on clean and simple abstractions :-)

--> towns