Can this design be refactored to a better Way?

Batch can be identified by using batchId and it has list of transaction
Transaction can be identified by using batchId and tranId, it has list of checks
Check can be identified by using batchId, tranId and checkId.

Is this a better way to design this or is there a better way to redesign these 3 classes, because even though "Transaction" class is part of "Batch" class we have "batchId" attribute in "Transaction" class? Similarly we have "batchId" and "tranId" in "Check" class. Please provide your inputs

If your answers is no, then why do you need batchId in Transaction and Check classes and also tranId in Check class. So if you want to enforce a rule that Check does not exist without Transaction, then you should define a private constructor in Check(so that no once create a check independently and it will be always created using Transaction) and initiate the List<Check> checkList with Transaction constructor, similarly Batch.

SCJP1.5, SCWCD5, SCEA5

Naresh Shanmugam
Ranch Hand

Joined: Jul 16, 2010
Posts: 86

posted Apr 18, 2012 20:11:18

0

Transaction object does not exist without batch, Similarly check object does not exist with out transaction.
We need batchId in Transaction because, a transaction is identified by batchId and tranId together. Though batch has list of transactions, some times when need to send one particular transaction object to other method for some processing, that time we may need batchId too, so we have created batchId in "Transaction" class. Do you think that this is not a proper approach?

Depending on your answer you might or might not remove the two-way into one-way.

And from this point of view, the check class seems to be an aggregate from transaction, so is there really a need to have batchId and tranId?
Can there be several checkDate of the batchId in the same day?

Is there a real need to have a history of checks or would saving the last done check be enough?

So in reality, I don't have enough information to know if you can do two-way directionality into one-way and do an inline class refactoring.