Okay, we’re back.  Just a point of note.  This post is after a long period of silence from my end….yes, I have a tendency to fall off the face of the Earth and it takes me a while to get back up….so what I have done this time around is revisited the earlier parts…did a little clean-up and I have rewritten Part 4 (now called “Focus on the Corridor Conversation”).  Please do take 5 minutes to re-read that part before proceeding.  The rest is more or less the same….okay lets press on.

So we have a nice, clean MyStashService with a line count of about 20 after the last post….and like we said in the last post, what about the rest of the “stuff”?  We can’t work an application with just this miniature MyStashService…in fact, is this really MyStashService we have arrived at?  Doesn’t feel like a full application without all the other stuff….so what is this we have ended up with?

Its a guy who knows how to credit or debit a balance – that’s about it – its not MyStashService.  Its not a guy who can get me the last 10 transactions…now that is definitely a feature that is going to come up somewhere down the road.  What can we call this guy?…..AccountingService?….Does that sound like what it is?….you still would expect an AccountingService to return you the last 10 transactions as well…the name AccountingService feels like just a synonym of MyStashService….hmm.  Designer’s Block yet again ;-).  As we said a couple of lines earlier, we do know that the methods in it seem to always modify the balance.  Lets try and break out of the Designer’s Block we find ourselves in by giving it an explicit name like BalanceModifier…even though it sounds a little weird for now….at least it now reads….this is a BalanceModifier….it can modify the balance by crediting it or debiting it…..am sure a better name will come to us sometime soon.

So lets do that quickly – may be create a new class called “BalanceModifier” and add the two crisp short methods of credit() & debit() to it.  While doing that lets make these methods static for now so that our original MyStashService can just call these two methods in its respective credit() & debit() methods:

public class BalanceModifier {

    // Credit the balance
    public static double credit(double balance, double theAmount) {
        return balance + theAmount;
    }

    // Debit the balance
    public static double debit(double balance, double theAmount) {
        return balance - theAmount;
    }
}

public class MyStashService {
    ...
    public void credit(double theAmount) throws SQLException {
        ...
        // Increase the balance by the amount
        balance = BalanceModifier.credit(balance, theAmount);
        ...
    }

    public void debit(double theAmount) throws SQLException {
        ...
        // Reduce the balance by the amount
        balance = BalanceModifier.debit(balance, theAmount);
        ...
    }
    ...
}

Here is a tip….in my head I like to personify my code (read design…code is design).  So it looks something like this in my head right now…the MyStashService guy now has help from the BalanceModifier guy who takes care of modifying the balance correctly for him

What else does the MyStashService guy need help with? Yes, all that other stuff…definitely. He is burdened with doing all that Database stuff with connections.  May be he needs a Database guy to help him with that stuff. If you step back and look at the credit or debit method implementation, he needs this database guy to fetch and save the balance from the database whenever he needs.

What should we call this guy? Database? Probably too generic? How about just MyStashDatabase or MyStashDB? So:

public class MyStashDB {

    public double fetchBalance() throws SQLException {
        // TBD
    }

    public void saveBalance(double balance) throws SQLException {
        // TBD
    }
}

Now we can move all that database related code, including the database parameters and relevant portions of the constructor from the MyStashService class into new guy/class.  MyStashService now reduces to:

public class MyStashService {

    private MyStashDB myStashDB;

    public MyStashService(MyStashDB myStashDB) {
        this.myStashDB = myStashDB;
    }

    // Record an income
    public void credit(double theAmount) throws SQLException {

        // Get Balance
        double balance = myStashDB.fetchBalance();

        // Increase the balance by the amount
        balance = BalanceModifier.credit(balance, theAmount);

        // Update Balance
        myStashDB.saveBalance(balance);
    }

    // Record expense
    public void debit(double theAmount) throws SQLException {

        // Get Balance
        double balance = myStashDB.fetchBalance();

        // Reduce the balance by the amount
        balance = BalanceModifier.debit(balance, theAmount);

        // Update Balance
        myStashDB.saveBalance(balance);
    }

    // Track my balance
    public double getBalance() throws SQLException {
        return myStashDB.fetchBalance();
    }
}

Look at the credit or debit method – doesn’t it just read like plain english or if you prefer – psuedo-code. Almost feels like a “Corridor Conversation”!

I have not listed the code for MyStashDB – that should be quite straight forward as you just have to move the code from the MyStashService class.  So now in my head it looks like:

So when MyStashService wants to do a credit he would do the following – 1, 2 & 3 as depicted below:

So far we have been looking at SRP from the point of view of the MyStashService.  Now that we have 2 other guys, you could start taking a look at SRP from the perspective of one of other guys – say MyStashDB.  You will be amazed at the further breakdown you will land up doing.  Think of classes like ConnectionFactory – should MyStashDB really care that it is a postgres database and how to get a connection for a postgres database – delegate out to ConnectionFactory? As you drill deeper and deeper or rather break things down further and further you would eventually start overlapping what framework’s such as hibernate and others already do 😉 – nope, I am not kidding.  I plan to do some follow-up posts of these series which would hopefully prove this right.  For now, lets stick to basics and not go that far.