Uncoupling Classes in Java in Very Coupled Business Logic

Question

I am writing a simulator as a first ambitious project to start learning Java and Object Oriented Analysis and Design (OOA&D). The simulator will compare different methods to manage inventories in supply chains (if more detail is required from the business part, please let me know).

I am having a hard time getting a decoupled design for my classes. Although the full version of the simulator has more classes, the classes that I'm having trouble with are:

• ProductData: this is basically a class designed to keep all the historical information available for the product. Each product has a set of standard properties, each of which has a different value for each date in the (recorded) history of the product. Following the design decision shown on page 448 of Head First OOA&D, I decided to use a Map to store each relevant property of the product for each date, and then have another collection to store each Map and the date those properties where valid (so that I can easily access each property by date). If a new algorithm in the future requires to track a new property, I can add it to the properties Map and then use it in the new Algorithm.
• RawResults: this class is another set of properties, broader than ProductData, because besides the basic product data, it needs to store all the calculated values of the simulation for each simulated date. Since each algorithm can require a different sub-set of specific "result" properties, besides the "basic" sub-set of properties that all algorithms share, each time we add a new property to the ProductData, that same "basic" property needs to be added to Rawresults. And since adding a new property to ProductData will almost always come as a result of adding a new Algorithm to the simulator, I will probably will need to add some more "result" properties to this class.
• Algorithm: this class is the "brain" of the simulator. It takes a ProductData object and reads the relevant properties for the algorithm, process them for each simulated date, and then stores the results in a (initially) blank RawResults object. At the end of the simulation I get a RawResults object with all the results of the particular simulation, which I can then process to compare to other simulations and draw conclusions. This will be an abstract class, and each particular algorithm will be a sub-class of Algorithm, each one implementing all of the required actions in a very specific way. I think that on this side the design is a little bit better (I hope), since adding new properties to ProductData and RawResults shouldn't imply a need to change my existing Algorithm subclasses, since they probably won't need to use those new properties anyway.

So my question is: is this really as good a decoupling I can get given the business logic coupling I'm facing? Can I apply any other strategies (which ones?) to help me design a more robust and flexible simulator?

Answer 1

Each entry in the ProductData map should probably be a member of a ProductDataEntry class (unless the data they contain varies wildly).

It sounds like RawResults might then be able to extend ProductDataEntry since it will have the same fields.

Overall your design sounds ok - there's no way to say more without looking at the actual objects and overall architecture though and this isn't the place for that (and I don't have the time).

To be honest at this stage in your programming career (and even later) you shouldn't be afraid to try things and throw them away if they don't work. Instead of spending 3 days trying to decide what to do spend 1 day on each of 3 prototypes trying a different method and then at the end look at what you learnt and what you liked and did not like from the prototypes.

Note that while uncoupling as much as possible is a good aim to have sometimes the nature of a problem is such that things are tightly coupled. Don't bend the whole architecture out of shape to fight it when that happens - just make sure that they really do need to be coupled as tightly as they are.