Don't Repeat Yourself (DRY) - Part Three

Here, we will talk about code bits that are not 100% identical but follow the same pattern and can clearly be factored out.
 
Let us continue with our discussion on DRY. We discussed the below two issues in our previous tutorials.
In this tutorial, we are going to discuss another issue -- Repeated Execution Pattern. First, you should brush up your knowledge about Don't Repeat Yourself (DRY) Design Principle.
 
Let's take a look at one example.
  1. public class Issue {  
  2.     public static void DoSomething() {  
  3.         WriteToConsole("Araham""a good friend", 30);  
  4.     }  
  5.     public static void DoSomethingAgain() {  
  6.         WriteToConsole("Pramod""a neighbour", 54);  
  7.     }  
  8.     public static void DoSomethingMore() {  
  9.         WriteToConsole("Praseedha""my sister", 45);  
  10.     }  
  11.     public static void DoSomethingExtraordinary() {  
  12.         WriteToConsole("Nayana""my daughter's best friend", 4);  
  13.     }  
  14.     public static void WriteToConsole(string name, string description, int age) {  
  15.         Console.WriteLine(string.Format("{0}, {1}, age - {2} ", name, description, age));  
  16.     }  
  17. }  
  18. class Program {  
  19.     static void Main(string[] args) {  
  20.         Console.WriteLine("About to run the DoSomething method");  
  21.         Issue.DoSomething();  
  22.         Console.WriteLine("Finished running the DoSomething method");  
  23.         Console.WriteLine("About to run the DoSomethingAgain method");  
  24.         Issue.DoSomethingAgain();  
  25.         Console.WriteLine("Finished running the DoSomethingAgain method");  
  26.         Console.WriteLine("About to run the DoSomethingMore method");  
  27.         Issue.DoSomethingMore();  
  28.         Console.WriteLine("Finished running the DoSomethingMore method");  
  29.         Console.WriteLine("About to run the DoSomethingExtraordinary method");  
  30.         Issue.DoSomethingExtraordinary();  
  31.         Console.WriteLine("Finished running the DoSomethingExtraordinary method");  
  32.         Console.ReadLine();  
  33.     }  
  34. }  
We’re simulating a simple logging function every time we run one of these “DoSomething” methods.
 
The pattern is clear
  • Write a message to the console, carry out an action, and write another message to the console.
  • The actions have an identical void, parameter-less signature.
  • The logging message all have the same format, it’s only the method name that varies.
  • If this chain of actions continues to grow then we have to come back here and add the same type of logging messages.
  • Also, if you later wish to change the logging message format then you’ll have to do it in many different places
Lets us see how we can refactor the above code.
 
The first step is to factor out a single console-action-console chunk to its own method.
  1. private static void ExecuteStep() {  
  2.     Console.WriteLine("About to run the DoSomething method");  
  3.     Issue.DoSomething();  
  4.     Console.WriteLine("Finished running the DoSomething method");  
  5. }  
This is, of course, not good enough as the method is very rigid. It is hard coded to execute the first step only.
 
We can vary the action to be executed using the Action object,
  1. private static void ExecuteStep(Action action) {  
  2.     Console.WriteLine("About to run the DoSomething method");  
  3.     action();  
  4.     Console.WriteLine("Finished running the DoSomething method");  
  5. }  
We can call this method as follows,
  1. class Program {  
  2.     static void Main(string[] args) {  
  3.         ExecuteStep(Issue.DoSomething);  
  4.         ExecuteStep(Issue.DoSomethingAgain);  
  5.         ExecuteStep(Issue.DoSomethingMore);  
  6.         ExecuteStep(Issue.DoSomethingExtraordinary);  
  7.         Console.ReadLine();  
  8.     }  
  9.     private static void ExecuteStep(Action action) {  
  10.         Console.WriteLine("About to run the DoSomething method");  
  11.         action();  
  12.         Console.WriteLine("Finished running the DoSomething method");  
  13.     }  
  14. }  
Except that we’re not logging the method names correctly. That’s still hard coded to “DoSomething”.
 
That’s easy to fix as the Action object has public properties to read off the method name,
  1. private static void ExecuteStep(Action action) {  
  2.     string methodName = action.Method.Name;  
  3.     Console.WriteLine("About to run the {0} method", methodName);  
  4.     action();  
  5.     Console.WriteLine("Finished running the {0} method", methodName);  
  6. }  
We’re almost done,
  • If you look at the Main method then the ExecuteStep (somemethod) is called 4 times. That is also a form of DRY-violation.
  • Imagine that you have a long workflow, such as the steps in a chemical experiment. In that case, you may need to repeat the call to ExecuteStep many times.
We can instead put the methods to be executed in a collection of actions,
  1. private static IEnumerable < Action > GetExecutionSteps() {  
  2.     return new List < Action > () {  
  3.         Issue.DoSomething, Issue.DoSomethingAgain, Issue.DoSomethingExtraordinary, Issue.DoSomethingMore  
  4.     };  
  5. }  
You can use this from within Main as follows,
  1. class Program {  
  2.     static void Main(string[] args) {  
  3.         var actions = GetExecutionSteps();  
  4.         actions.ToList().ForEach(action => {  
  5.             ExecuteStep(action);  
  6.         });  
  7.         Console.ReadLine();  
  8.     }  
  9.     private static void ExecuteStep(Action action) {  
  10.         string methodName = action.Method.Name;  
  11.         Console.WriteLine("About to run the {0} method", methodName);  
  12.         action();  
  13.         Console.WriteLine("Finished running the {0} method", methodName);  
  14.     }  
  15.     private static IEnumerable < Action > GetExecutionSteps() {  
  16.         return new List < Action > () {  
  17.             Issue.DoSomething, Issue.DoSomethingAgain, Issue.DoSomethingExtraordinary, Issue.DoSomethingMore  
  18.         };  
  19.     }  
  20. }  
Now, it’s not the responsibility of the Main method to define the steps to be executed. It only iterates through a loop and calls ExecuteStep for each action.
 
Thanks for watching the tutorials. I appreciate your feedback.