NOTE: It’s been a while & as I was reviewing the previous posts of this series,  I decided to delete the last bit of the previous post (“The Designer’s Block: The Database Guy…”) which directly puts an interface unifying all DAOs.  Decided to evolve it a little slower & hopefully a bit better.

The pattern we were chasing up in the last post was really leading to a single DAO interface.  Let’s make another attempt.  Let’s pick up the DAOs having the most synergy.  Clearly the ICreditDAO & IDebitDAO.  I think it is a no brainer that these literally are the same with a difference of a transaction type indicating that one is a credit and the other is a debit.  You either receive money or spend it.  Should be fairly straight forward to unify them.  

Heads up….discussion below digresses from the database guy.  This talk of unifying the credit & debit triggered an important point that I think should be covered.  We shall get back to the database guy in the next post.

But what would we name it?

So far we have been using the term “transaction” for this in the database.  If you noticed the SQL queries, we used it for the table name – transaction_log, txntype (transaction type).  Should we go with that?  ITransactionDAO?  

public interface ITransactionDAO {

   void insertTransaction(
           @NotNull final TransactionInfo theCredit);
}

Funnily enough we already had a TransactionInfo.  We defined it when we put a signature for the method of retrieving the last 10 transactions.  Note, I used “insert” rather than “save” in the method signature.  “Save” gives the impression that this method may also do an update of a record.

Shall we move on? Are you sure?  To confirm let’s review what a TransactionInfo looks like now.  My guess is that, currently in your mind, you are thinking, it’s similar to the CreditInfo or the DebitInfo, take your pick, with an added TransactionType to indicate if it is a credit or a debit.  So something like this, is what I am guessing:

public class TransactionInfo {

   public enum CreditOrDebit {
       CREDIT, DEBIT;
   }

   private CreditOrDebit creditOrDebit;

   private double amount;

   private String description;

   private Date date;

   public TransactionInfo(
           @NotNull final CreditOrDebit creditOrDebit,
           final double amount,
           @NotNull final String description,
           @NotNull final Date date) {

       this.creditOrDebit = creditOrDebit;
       this.amount = amount;
       this.description = description;
       this.date = date;
   }
   ...
}

Here’s a tip.  When you transfer money from one stash to another, is that a transaction?  In its current state, would you call ITransactionDAO twice?  A debit to one stash and an equivalent credit to another stash?  So have you done two transactions or would you like to say you did one transaction of funds transfer?  If the debit is not possible, say for insufficient funds, would you still do the credit?  So many such questions arise when you step back and review a term used and dig deep into analyzing what it actually means “in the domain” & what you are using it for.  So much so that you get confused yourself and need a break.  Has happened to me many a time.  I would just get up and go for a walk and ponder on it.  What is a transaction?  What do I want it to mean in this world?

The key thing to be cognizant of, is that for most softwares being built, once a term is established in its vocabulary, it gets stickier over time. There is rarely time & opportunity to get back & change it.  It becomes more & more etched in stone.  It is extremely important to spend the time and come up with meaningful names for classes, interfaces, methods, etc.  This is not to say that you will get it right the first time.  It will take  several iterations to gain some sense of legitimacy.  But don’t lose heart, keep going back and keep at it.

Here is another example of a suspect name we have already been touting about.  Any guesses?  The central name itself, “MyStash”.  We have used it, and I must use the term, “frivolously” in several places.  All for the sake of being cool.  So is there going to be a “YourStash” too?  What do we really mean by “My” in the word “MyStash”?

Coming back to what we were doing.  What would be a good term to unify a credit and a debit entry?  Now we are getting into the nuts & bolts of the domain we are building the software for.  Software developers are hardly domain experts from the get go.  Always seek out the true domain experts to see if they actually have a term for something you are struggling with.  Overtime, you would gain more expertise in the domain, enough to stand tall.

Since I don’t have a domain expert at hand, am going to limit the terms to the best of my accounting knowledge.  Ever visited a Bank?  In the good old days, when there were no computers, record keeping of financial transactions were done using a large book.  The “Ledger”.  Ring a bell?  Now isn’t that a better word than something invented – “TransactionLog”?  I think so.  And since you aren’t here to debate about it ;-), am going to go ahead and use it.  You make credit & debit “entries” into a Ledger.  So we’re going to call those LedgerEntry(s).  So we shall now have a ILedgerDAO which is going to help record credit & debit LedgerEntry(s) into the Ledger.

This revised taxonomy can be applied to all the architectural layers…which we should see happening shortly in the upcoming posts.