Yes! I fell off the earth again…I keep doing that….but I try & not give up….come back / get back on the saddle at some point in time…needless to say, I apologize for this behavior…am truly sorry.

In restarting this series, which I am actually quite passionate about…where I left off on Part 4 – what I have done is rewritten Part 4 after reviewing everything from Part 1 to 4…hope to now again continue the episodes.

Hope I made enough sense in the “Gyan” or I should more rather call it a rant of Part 3 for you to be still reading Part 4.  So let’s come down to the problem at hand, the “My Stash” Application and the code we have created so far. Clearly, the one class we created is doing too many things.

Let’s look at the credit() method alone and see if we can come up with a better design for it.  Let’s start applying SRP principles right away, but not at the class level yet, let’s start off at the method level – start off simple, realizing that SRP really applies at every level and every situation – you sit down to do something, just do that one thing with full focus and not mix it up with too many other things.  Remind me to tell you what my sister once told me about something they follow when they get out of the house with their toddler….oops sorry, I digress, coming back…

If someone were to ask me in a corridor conversation – what the credit method does at a high level? – I would probably say…..”oh! its simple, it just increases the balance by the specified credit amount”.

Really!  Take a look at the code that we just wrote….your answer should have probably been…it….

• Creates a database connection and…
• Fires a query against the “mystash” table to get the value of the “balance” column to get the …
• current balance…and then…
• Increments the balance by the specified amount…and then
• Updates the “balance” column in the “mystash” column with this new balance
• ….oh! and if any problem occur it keeps track of the old balance and reverts it back
• …in addition to informing the client what has transpired

So why the “impedance mismatch”?

I think the secret lies in the SOLID principles…..starting with my personal favorite we are discussing in this article called SRP – Single Responsibility Principle!  It is telling you that YOUR implementation of the credit method should strive to do JUST what you stated in the corridor conversation, that should be its sole responsibility.  It should not care about:

• How to create a database connection
• Where the current balance is stored
• How to update it
• What to do if there are any problems

These are NOT its responsibilities….someone else (read some other classes) should worry about each of the above. Its almost crying out, and telling you, can you please delegate the above stuff to someone else so that I can just be:

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

Yes a 1 Line method ignoring all the comments and stuff….whats the NCSS metric on this…1!  Now that’s a joke, wonder what the NCSS on the previous implementation was?

(NCSS – Non Commenting Source Statements, please do look it up, I think it is an invaluable source code metric)

But…but….whose going to do the rest of the stuff?  Clearly the application is not going to work as a whole without the other stuff….balance needs to be saved, exceptions need to be handled….Yes! they do, but by other classes.  The credit() method should not have to care about all that stuff….you can store the balance in an XML file or an Oracle Database for all it cares…..it should not have to deal with that detail!

public class MyStashService {

    // Credit the balance
    public double credit(double balance, double theAmount) {

        // Increase the balance by the amount
        return balance + theAmount;
    }

    // Debit the balance
    public double debit(double balance, double theAmount) {

        // Reduce the balance by the amount
        return balance - theAmount;
    }
}

Hmm…with all the commenting…about 20 lines…..to deal with the core functionality of credit and debit….can be nicely unit tested I must say.  I don’t know about you guys, but I do feel like I am dealing with a lot less clutter and feel super confident in fixing bugs that come up in this area.  I feel I am actually doing some design!

What happens to the rest of the stuff that these methods used to do?….getting there…but quite frankly, as a start – may be just try creating a class for each of the unique responsibilities….