Post
Ask Question

Table Driven Design

Table Driven Design is an alternative to switch-case and if-else statements. Memorized key-value pairs are the main trick. You can fill a dictionary of <Key, Value> pairs and wait for a key value from an upper level such as DAL. 

Re-engineering is necessary

Re-engineering is necessary. Your project or class or method can have more complex situations. Therefore, you should  be organized into multiple sections. Switch-case and if-else statements are kinds of ways to separate sections for any situation. The logic of re-engineering of those systems should indicate a considerable reduction in effort. The problem here is to restructure the existing program code by minimizing time for future maintenance. Writing more spaghetti code has produced more a tangled code pattern. A programmer must concentrate on:

  • Responsiveness

    Improving the accessibility, quality and timeliness of client services.

  • Simplification

    Streamlining the administrative process.

  • Integrity

    Ensuring the correctness of system operation and data.

  • Productivity

    Enabling employees to provide the highest quality service at minimum cost.

 Before Table Driven

tngle.png

Yes! Business rules and procedures are frequently affected by outside influences. But managers expect to keep pace with changes. Managers expect you to change code design quickly, effectively and economically.

Let's talk about a sample: You have a database class which has two properties in the real-world; your database class' source from database but I mimicked it by using some code; look below. (Database class.) The main program has been designed using a switch-case statement by returning a value from the database.  

Code

namespace TableDrivenApp
{
      class Program
      {
          static void Main(string[] args)
          {
              Db db = new Db();
              string Message =db.Message;  // <----- Message from DataBase
              DocumentType dt = 
                  (DocumentType)Enum.Parse(typeof(DocumentType), db.FormatType);  // <-----Type from DataBase
              switch (dt)
              {
                  case DocumentType.Pdf: new PdfHander().Write(new Format() 
                      { Data = Message, MessageType = dt });
                      break;
                  case DocumentType.Word: new WordHandler().Write(new Format() 
                     { Data = Message, MessageType = dt });
                      break;
                  case DocumentType.Excel: new ExcelHandler().Write(new Format() 
                     { Data = Message, MessageType = dt });
                      break;
                  default:
                      break;
              }
        }}

    public class Db
    {
        public string Message { get; set; }
        public string FormatType { get; set; }

        public Db()
        {
            Message = "Hello Pdf! ";
            FormatType = "Pdf";
        }
    }
}


The above code looks normal. But to be honest, adding switch case and if-else statements is boring; also keeping track of that code is not easy for every programmer. Code tracking becomes more expensive than before. At the beginning of the project, more complex structure doesn't exist here. However, our main goal is to eliminate the need for any knowledge of what is coming from the database. We can reduce the complexity by using Table Driven Development.

Table Driven Development

Table driven is based on key value pairs. Separation of Concerns is an essential milestone. I separated three classes in my tiny project: ExcelHandler, PdfHandler and WordHandler which are implemented from IHandler. Also I have a controller class named DocumentManager.cs.

tdd.png

Code

public class DocumentManager
{
    private Dictionary<DocumentType, IHandler> handlers = new Dictionary<DocumentType, IHandler>()
    {
        { DocumentType.Pdf, new PdfHander() },
        { DocumentType.Word, new WordHandler() },
        { DocumentType.Excel, new ExcelHandler()}
    };
    public void RUN(Format message)
    {
        handlers[message.MessageType].Write(message);
    }
}

DocumentType  is an enum which has Pdf, Word and Excel. The Format class includes the Enum Type. By calling the RUN method from the UI, you will utilize PdfHandler, WordHandler etc. 

Usage

static void
Main(string[] args)
{
    Db db = new Db();
    string Message =db.Message;  // <----- Message from DataBase
    DocumentType dt = (DocumentType)Enum.Parse(typeof(DocumentType), db.FormatType);  // <-----Type from DataBase
    new MyDocument().Run(Message, dt);
}

The workload is reduced. Thus, depending on the information coming from the databases of N; the DocumentManager will do the management for us. The Dictionary is private so the UI developer doesn't have any idea about this structure. Everything is ok for SOC (Separation of Concerns). All action columns have been clearly identified in the decision table.

Pros and Cons Table Driven Development

Pros Cons
Enabling apply SOC (Separation of concerns) exactly.  Hard coded is necessary.
Enabling follow code's flow.  Strong design pattern knowledge is necessary.
Maintenance is easy Needing more time to develop.

Summary

The Table Driven Design approach contributes to solving business problems, the design principles should be applied to business information systems. Table DrivenDesign is different from  traditional procedural design (switch-case) and may be not preferable by developers due to time requirements. However, table driven is more clear; also you can make maintenance more easily, instead of switch-case and if-else statements.

References:

http://www.cihataltuntas.com/refactoring-table-driven-methods/

http://dkl.com/html/CMFiles/53table_driven_design.pdf


Similar Articles