我们需要创建一个服务程序,它接受一个业务,然后提交,我们决定先简单创建一个对象,这个对象只包含一个公共方法来完成这件事情,具体需求如下:
1,交易信息开始于一串标准ASCII字符串;
2,这个信息字符串必须转换成一个字符串的数组,数组存放的值是此次交易用到的领域语言中所包含的词汇元素;
3,每一个词汇元素必须标准化;
4,包含超过150个词汇元素的交易,应该采用不同于小型交易的方式来提交,以提高效率;
如果提交成功,API返回true,失败,返回false;
采用意图导向的编程思想,我们可以试着写出如下的代码(来源于书):
public calss Transaction{
public Boolean commit (string command){
Boolean result =true;
string[] tokens=tokenize(command);
normalizeTokens(tokens);
if(isAlargeTransaction(tokens)){
result = processlargeTransaction(tokens);
} else{
result = processSmallTransaction(tokens);
}
return result;
}
}
commit方法是我们为这个对象定义的应用程序接口,当然,他是公共方法,这样才能交给客户端对象,为他们提供服务,所有其他方法(如tokenize(),isAlargeTransaction(),processSmallTransaction()等)都不属于这个对象的一部分,而仅仅是实现过程中的功能性步骤。
采用这样的编程意义何在呢?用这样的编码方式,我们可以把精力集中在如何分解最终目标,以及那些全局性的问题上。优点是显而易见的:
1、 更加内聚;
2、更加清晰可读;
3、更易于调试;
4、更易于重构和优化,所以只做最少的设计,满足当前需求;
5、在一个团队中更方便分工合作,我们可以把合适的方法交给擅长的人去做;
6、更易于单元测试以及维护等等;
作者在书中对这些优点进行了更加深入细致的阐述;再次我就不一一去写了,总的来说,我觉得这样一种方法,就是先采用自顶向下来得到一个完整的结构,就像书本目录一样,确认把目录做好了以后,再去一个个实现目录里边的内容,说到这里,我感觉编程方法和书本很像,我们既可以先写内容再做目录,也可以先做目录再写内容,两种方法写出来的书读起来感觉肯定是不一样的,个中乐趣,只有写书人和读书人能够体会的了,我希望通过记录这样一种方法,自己以后在实践中可以融汇贯通,我一直觉得一个没有思想的程序员不能叫程序员,编程是一个体力活,而优秀的设计思想和对实现对象的理解才是一个程序员的灵魂所在。
个人学识浅薄,要是有什么不对的地方还请批评指正,丢脸不可怕,可怕的是不知道自己错了还以为是对的。如果你也对这方面感兴趣,欢迎探讨。