What Is Table-Driven Design?

If you've ever been to a restaurant and had a waiter, come up to your table and ask, "would you like fries with that?" and then proceeded to follow up with a question about whether you'd like cheese on top of those fries, then you're already familiar with the table-driven design! A table-driven software engineering approach simplifies and generalizes applications by separating program control variables and parameters (rules) from the code and placing them in separate external tables. The goal is to decouple program control data from application logic and emphasize modularity to ease change management. When you think of a table, do you think of a nice place to have dinner? or maybe you think of a piece of furniture that holds your clothes. What if I told you that tables are the best way to transform information from one kind into another? Yes, that's right. You can change the names of cities, the distances between them, their populations, or land area differences depending on the information available in other tables or parts of the same table. You can also use decision tables to directly transform collections of conditions into a series of actions or procedures. Using tables makes it easy for designers/programmers to understand what they're doing immediately because they represent relationships graphically and concisely. Those things have value if we've learned anything from eating at restaurants and organizing our closets! Tables are an excellent way to collect data, but they aren't the only way. Tables are just one form of a table-driven design. What's a table-driven plan? Well, it's when a program uses something other than a table to organize its data. The program could use an array instead of a table or maybe it's using lists or files or even graphs and charts! But just because a program uses those things doesn't mean that it's using a table-driven design it just means it's using some data structure!