• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Problem in calculating financial objects with cyclic dependencies

Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've the following problem and need a piece of advice in design.

There are two classes of business objects from financial domain: A and C, and A contains a collection of C. An user may request to calculate (refresh the indexes, recalculate the debt and so on) the objects of this classes. The problem is that A requires some data from the collection of C to be fully calculated and C, also requires some data from A to be fully calculated. Currently, all the calculations are done in on class , fortunately not in one method. This design is in conflict with clean code principle (the code is very messy and unclear) and I'd like to refactor the code. The problem lies in the two-way dependencies.

My idea is to create AbstractCalculator class which will hold the currentlyCalculatedA and other common fields that are required for calculation (configuration, info-services). Then I will create ACalculator and CCalculator that both extend AbstractCalculator, also ACalculator has an instance of CCalculator.
Then in ACalculator:
- A is calculated till possible
- Collection<C> is calculated with usage of CCalculator
- A is calculated till the end
- the state of AbstractCalculator is reseted and waits for the next calculation.

Here is the diagram:

Will it be good designed or maybe someone has a better idea?

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic