Table-Driven Design 表驱动设计

:本文所有代码来自 http://www.codeproject.com/Articles/42732/Table-driven-Approach

在许多程序中,经常需要处理那些拥有种种色色不同特性的实体,最直接的思路是用case语句或者if-else语句处理这些不同的实体。然而,如果这类实体的数量若足够庞大,将会产生大量代码,臃肿并难以整理和维护。

先通过一对实例感受一下:

// A text adventure game
if(strcmpi(command, "north") == 0) {
    if(cur_location->north)
        GoToLocation(cur_location->north);
    else
        Print("Cannot go there");
}
else if(strcmpi(command, "east") == 0) {
    if(cur_location->east)
        GoToLocation(cur_location->east);
    else
        Print("Cannot go there");
}
else if(strcmpi(command, "south") == 0) {
    if(cur_location->south)
        GoToLocation(cur_location->south);
    else
        Print("Cannot go there");
}
else if(strcmpi(command, "west") == 0) {
    if(cur_location->west)
        GoToLocation(cur_location->west);
    else
        Print("Cannot go there");
}

相同功能的其他代码:

enum SIDE {SIDE_NORTH = 0, SIDE_EAST, SIDE_SOUTH, SIDE_WEST};
struct COMMAND {
   const char * name;
   SIDE side;
};
static const COMMAND commands[] = {
   {"north", SIDE_NORTH},
   {"east", SIDE_EAST},
   {"south", SIDE_SOUTH},
   {"west", SIDE_WEST},
};
for(int i = 0; i < NUM_OF(commands); i++)
    if(strcmpi(commands[i].name, command) == 0) {
        SIDE d = commands[i].side;
        if(cur_location->sides[d])
            GoToLocation(cur_location->sides[d]);
        else
            Print("Cannot go there");
    }

从上面两段代码我们可以看出,第二段将实体从条件语句中分离出来,使得程序框架更加清晰;为了增加command names,现在只需要在一处修改代码。当数据量足够大时,可以分很方便地增添、删减或者替换,非常有利于维护。

正式定义前,再用一对代码来加强理解。(举例来自书籍《Refactoring》,Martin Fowler

// calculating the price for renting a movie
double result = 0;
switch(movieType) {
   case Movie.REGULAR:
     result += 2;
     if(daysRented > 2)
        result += (daysRented - 2) * 1.5;
     break;

   case Movie.NEW_RELEASE:
     result += daysRented * 3;
     break;

   case Movie.CHILDRENS:
     result += 1.5;
     if(daysRented > 3)
        result += (daysRented - 3) * 1.5;
     break;
}

使用数组后的优化解决方案:

enum MovieType {Regular = 0, NewRelease = 1, Childrens = 2};

                             // Regular   NewRelease   Childrens
const double initialCharge[] = {2,             0,        1.5};
const double initialDays[] =   {2,             0,          3};
const double multiplier[] =    {1.5,           3,        1.5};

double price = initialCharge[movie_type];
if(daysRented > initialDays[movie_type])
    price += (daysRented - initialDays[movie_type]) * multiplier[movie_type];

以上举例能非常明显的展现出表驱动设计的优点:Table-Driven代码更快、更短、更容易维护!

如果使用表驱动来整理在之前博客中写到的迷宫问题,代码最少可以简短200行!学到的太晚了!

在此给出Table-Driven Design定义:

表驱动设计是软件开发工程中的一种方法,通过从程序代码中分离的控制变量以及参数并将其存储在外部表格中的处理来简化、概括程序。主要目的在于将控制变量从程序逻辑中脱离以及着重于构建程序的模块化框架,来减轻因变更数据产生的管理工作量。

人类是智慧的,代码是伟大的!如同现实世界一样,计算机世界也有着太多东西值得我们去探索和发现!

加油吧!少年们!

       大三上

                                                                                                                   2016/11/15 上午

时间: 2024-11-09 02:09:20

Table-Driven Design 表驱动设计的相关文章

领域驱动设计(DDD:Domain-Driven Design) 转摘自:http://www.jdon.com/ddd.html

Eric Evans的“Domain-Driven Design领域驱动设计”简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法,本站Jdon.com是国内公开最早讨论DDD网站之一,可订阅DDD专题.初学者学习DDD可从研究本站Jdon框架的DDD应用源码开始,戳这里开始. 过去系统分析和系统设计都是分离的,正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样,这样割裂的结果导致,需求分析的结果无法直接进行设计编程,而能够进行编程运行的代码却扭曲需求,导致客

领域驱动设计战略原则

之前发在别的地方了,据说标题不好,改个标题... 去年就打算总结一下,结果新换的工作特别忙,就迟迟没有认真动手.主要内容是很多初学DDD甚至于学习很长时间的同学没有弄明白DDD是什么,适合什么情况.这世界上没有银弹,抛开了适合的场景孤立的去研究DDD,在学习过程中还可以,但是应用到实际项目时就会遇到各种坑,到头来各种妥协,我看到很多同学遇到这种情况,最后怪DDD,说DDD不实用云云.另有一些都没细了解过就抨击反对的,事实上,要想否定个东西,你总要了解了才有发言权. 一.误区 综合起来主要有一下几

DDD(领域驱动设计)

模型驱动设计(Domain Driven Design) 模型关系图(Model-Driven Design) 领域驱动设计中的模型关系图如下: 层结构(Layered Architecture) User Interface 负责向用户展现信息,并且会解析用户行为,即常说的展现层. Application Layer 应用层没有任何的业务逻辑代码,它很简单,它主要为程序提供任务处理. Domain Layer 这一层包含有关领域的信息,是业务的核心,领域模型的状态都直接或间接(持久化至数据库)

什么是领域驱动设计(Domain Driven Design)?

本文是从 What is Domain Driven Design? 这篇文章翻译而来. ”…在很多领域,专家的作用体现在他们的专业知识上而不是智力上.“ -- Don Reinertsen 领域驱动设计(Domain Driven Design)是一种软件开发方法,目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程的调整而调整. 传统的开发工作趋向于一种以技术为先导的过程,需求从业务方传递到开发团队,开发人员依据需求上的描述创造出最有可能的假想. 在瀑布开发过程中,这导致

领域驱动设计(Domain Driven Design)参考架构详解

转自:http://blog.csdn.net/bluishglc/article/details/6681253 领域驱动设计(Domain Driven Design)参考架构详解 摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.

[转载]领域驱动设计(Domain Driven Design)参考架构详解

摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.csdn.net/bluishglc/article/details/6681253 转载请注明出处! 目录 1.      架构概述2.      架构详解        2.1.  

状态模式在领域驱动设计中的使用(Using the State pattern in a Domain Driven Design)

领域驱动设计是软件开发的一种方式,问题复杂的地方通过将具体实现和一个不断改进的核心业务概念的模型连接解决.这个概念是Eric Evans提出的,http://www.domaindrivendesign.org/这个网站来促进领域驱动设计的使用.关于领域驱动设计的定义,http://dddcommunity.org/resources/ddd_terms/,这个网站有很多的描述,DDD是一种软件开发的方式: 1.      对于大多数的软件项目,主要的精力应该在领域和领域的逻辑. 2.     

[译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章地址: [译文]Domain Driven Design Reference(一)—— 前言 [译文]Domain Driven Design Reference(二)—— 让模型起作用 [译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块 Ⅱ.模型驱动设计的

[译文]Domain Driven Design Reference(四)—— 柔性设计

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章地址: [译文]Domain Driven Design Reference(一)—— 前言 [译文]Domain Driven Design Reference(二)—— 让模型起作用 [译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块 [译文]Domai