This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I am trying to determine a good way to structure an application that I want to build.
I have been struggling with this for some time, drawing faux-UML, crossing stuff out, drawing more faux-UML, uttering mild expletives, crossing more stuff out, etc. and I keep catching myself thinking: There has to be a pattern for this.
I am confused enough that I am pretty sure any explanation of the problem is going to be intolerably messy... here goes:
A person can have - assets - liabilities - income streams - expense accounts
Each of these are structured differently, and behave differently.
On the other hand, all of these have 'movements' which need to be tracked to specific dates, and I need to be able to generate various displays based on the movements.
These displays will generally be 'monthly', 'quarterly', or 'yearly'. Or they will be breakdowns by account/category.
I seem to be able to structure my data so that either one or the other option is viable, but not both.
I guess my biggest problem is: How do I structure the statement and movements so that I can get efficient displays of both separate accounts (breakdown) and overviews by period?
Does anyone have any suggestions as to how to approach this?
My advice would be to forget efficiency for now. Find a structure that makes sense from a behavioural point of view - what objects will have what responsibilities, and how they will need to collaborate.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
You didn't show an entity for "movement" or transaction. I'd expect to see a collection of events that record a history or audit trail of what happened when. They might be very simple with fields for date, amount, from and to.
Once you have those, your displays might come very easily by iterating the collection and accumulating. I used to do a lot of this kind of thing:
That's assuming you want to do it all in memory. If you can create your displays from a database you can probably write a query to do most of the totals and breaks for you.
Does that seem to fit the problem?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
However towards design and implementation you will still need to leverage considerable knowledge and insight into your particular business domain (as indicated in Domain Driven Design) - as the devil is often in the details.