Following Principles

Wednesday, April 9, 2008

A dictionary definition of principle often uses the word "law", but principles in software development still require judgment. Sometimes the judgment requires some technical knowledge, like knowing the strengths and weaknesses of a particular technology. Other times the judgment requires some business knowledge, like the ability to anticipate where change is likely to occur.

Asking someone to make a sensible judgment about a principle is difficult when all you see is a snippet of code in a blog. The code is outside of its context. Take Leroy's BankAccount class. We don't really know what sort of business Leroy works for, or even what type of software Leroy is building. Nevertheless, let's apply a few principles to see what's bothering Leroy.

Remaining Single

Does Leroy's original BankAccount class violate the Single Responsibility Principle? I think so. The class is opening text files for logging, calculating interest, and oh, by the way, it needs to provide all the state and behavior for a financial account, too. Even without knowing the context, it seems reasonable to remove the auditing cruft into a separate class. After writing some tests, and implementing a concrete auditing class, Leroy's BankAccount might look like the following.

public class BankAccount
{        
    
public void Deposit(decimal amount)
    {
        Balance += amount;
        _log.Write(
"Deposited {0} on {1}", amount, DateTime.Now);
    }

  
// ...
  
  
AuditLog _log = new AuditLog();

}

Leroy has an almost infinite number of choices to make before coming up with the above implementation, though. Leroy could have derived BankAccount from an Auditable base class, or forced BankAccount to implement an IAuditable interface. But what guides Leroy to this particular solution in the universe of a million possibilities are other principles - like the Interface Segregation Principle, and Composition Over Inheritance.

An Addiction to Auditing

Leroy might still frown at his class, feeling he has violated the Dependency Inversion Principle. Without any additional information, we have to trust Leroy's judgment when he decides to make some additional changes.

public class BankAccount
{        
    
public BankAccount (IAuditLog auditLog)
    {
        _log = auditLog;
    }

    
public void Deposit(decimal amount)
    {
        Balance += amount;
        _log.Write(
"Deposited {0} on {1}", amount, DateTime.Now);
    }

  
// ...
  
  
IAuditLog _log;
}

Perhaps Leroy already knew about some future changes in his auditing implementation, or perhaps Leroy just wanted to make his class more testable. Some of us view software as a massive heap of dependencies, and we fight to reduce the brittleness created by dependencies using inversion of control and dependency injection techniques. In some environments, this isn't needed. The principles to apply depend on the language you use, the tools you use, and ultimately depend on the problem the software is trying to solve.

Is There Still Something Wrong With This Code?

WWWTC has had a run of 19 episodes. I have some material for at least another 20. Problem is, most of the material deals with API trivia and edge cases you might never see. Interesting? To me, at least, but I'm thinking of introducing more squishy design type entries. I know a lot of people struggle to apply the latest frameworks and libraries, but design questions are always enlightening and produce the most spirited debate, giving us all something we can learn from.


Comments
Kalpesh Thursday, April 10, 2008
Design problems are a good way of checking oneself. keep them coming.

For auditing problem in example - wouldn't aspect oriented programming do the work better?

Also, I see that there are too many moving parts in the way we are developing things. Does the business require these things than a working software?

I realize the need of writing good, maintainable code. But "principles" are too many OR not followed enough such that they don't come naturally when writing code (and they become domain of expert only).
Nathan Low Tuesday, April 15, 2008
Hi Scott, your blogs are great! Your createProcessAsUser was a lifesaver for me, so I hope you don't mind me putting a link to your code on my site, http://www.ozzieinboston.typepad.com/, please have a look andlet me know if you have any objections.

Keep up the great posts!
Nathan Low Tuesday, April 15, 2008
Hi Scott, your blogs are great! Your createProcessAsUser was a lifesaver for me, so I hope you don't mind me putting a link to your code on my site, http://www.ozzieinboston.typepad.com/, please have a look andlet me know if you have any objections.

Keep up the great posts!
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!