设计模式中的模板方法模式在Ruby中的应用实例两则

实例一
今天你还是像往常一样来上班,一如既往地开始了你的编程工作。
项目经理告诉你,今天想在服务器端增加一个新功能,希望写一个方法,能对Book对象进行处理,将Book对象的所有字段以XML格式进行包装,这样以后可以方便与客户端进行交互。并且在包装开始前和结束后要打印日志,这样方便调试和问题定位。
没问题!你觉得这个功能简直是小菜一碟,非常自信地开始写起代码。
Book对象代码如下:

class Book
 attr_accessor :book_name, :pages, :price, :author, :isbn
end

然后写一个类专门用于将Book对象包装成XML格式:

class Formatter 

 def format_book(book)
  puts "format begins"
  result = "<book_name>#{book.book_name}</book_name>\n"
  result += "<pages>#{book.pages}</pages>\n"
  result += "<price>#{book.price}</price>\n"
  result += "<author>#{book.author}</author>\n"
  result += "<isbn>#{book.isbn}</isbn>\n"
  puts "format finished"
  result
 end 

end 

调用代码如下:

book = Book.new
book.book_name = "Programming Ruby"
book.pages = 830
book.price = 45
book.author = "Dave Thomas"
book.isbn = "9787121038150"
formatter = Formatter.new
result = formatter.format_book(book)
puts result

你写好了之后,迫不及待地开始运行,运行结果也完全符合你的期望。

项目经理看完后,对你非常满意,小伙效率很高的嘛!你也非常的得意。
不过两天之后,项目经理又找到了你,他说之前没有考虑到需要交互的客户端还包括手机设备,而手机设备都比较吃流量,用XML格式来传输太耗流量了,想最好能改成使用JSON格式传输。但是之前的XML格式也要保留,最好可以由客户端指定使用哪种格式。
你有些不开心,心里低估着,为什么一开始不考虑周全呢,现在又要改遗留代码。但对方毕竟是领导,你还是要服从命令的,于是你开始修改Formatter类:

class Formatter 

 def format_book(book, format)
  puts "format begins"
  result = ""
  if format == :xml
   result += "<book_name>#{book.book_name}</book_name>\n"
   result += "<pages>#{book.pages}</pages>\n"
   result += "<price>#{book.price}</price>\n"
   result += "<author>#{book.author}</author>\n"
   result += "<isbn>#{book.isbn}</isbn>\n"
  elsif format == :json
   result += "{\n"
   result += "\"book_name\" : \"#{book.book_name}\",\n"
   result += "\"pages\" : \"#{book.pages}\",\n"
   result += "\"price\" : \"#{book.price}\",\n"
   result += "\"author\" : \"#{book.author}\",\n"
   result += "\"isbn\" : \"#{book.isbn}\",\n"
   result += '}'
  end
  puts "format finished"
  result
 end 

end

调用代码如下:

book = Book.new
book.book_name = "Programming Ruby"
book.pages = 830
book.price = 45
book.author = "Dave Thomas"
book.isbn = "9787121038150"
formatter = Formatter.new
result = formatter.format_book(book, :xml)
puts result
result = formatter.format_book(book, :json)
puts result

再次运行程序,得到了以下结果。

项目经理看到运行结果后开心地说:“太好了,这正是我想要的!”
可是你这次却没有那么开心,你觉得代码已经有些混乱了,XML格式的逻辑和JSON格式的逻辑混淆在一起,非常不利于阅读,而且如果以后还需要扩展功能也会非常困难。好在传输格式一般也就XML和JSON了,应该不会再有什么扩展了,你这样安慰自己道。
但幻想总会被现实打破,“我最近听说有个YAML格式挺好玩的.......” 项目经理说道。这个时候你已经有想打人的冲动了!!!

很多时候就是这样,在公司里写的代码乱七八糟,质量极差,很大一部分原因就是因为需求变来变去。我们不断在原有代码基础上补充各种后续加入的情况,在一行行新增的if语句下面,我们的代码变得不堪入目。当然,我们作为程序员,对于需求这种东西没有太多的话语权,在这方面我们无能为力。但是我们可以尽量地把程序的架构设计好,让我们写出的代码更具有扩展性,这样就可以应对各种需求变更了。

下面你将要使用23种设计模式中的模板方法来改进以上程序。
首先要定义专门的子类来处理每种传输格式的具体逻辑,这样不同传输格式的逻辑可以从一个方法里分离开,明显便于阅读和理解。
定义类XMLFormatter继承自Formatter,里面加入处理XML格式的具体逻辑:

class XMLFormatter < Formatter 

 def formating(book)
  result = "<book_name>#{book.book_name}</book_name>\n"
  result += "<pages>#{book.pages}</pages>\n"
  result += "<price>#{book.price}</price>\n"
  result += "<author>#{book.author}</author>\n"
  result += "<isbn>#{book.isbn}</isbn>\n"
 end 

end

定义类JSONFormatter继承自Formatter,里面加入处理JSON格式的具体逻辑:

class JSONFormatter < Formatter 

 def formating(book)
  result = "{\n"
  result += "\"book_name\" : \"#{book.book_name}\",\n"
  result += "\"pages\" : \"#{book.pages}\",\n"
  result += "\"price\" : \"#{book.price}\",\n"
  result += "\"author\" : \"#{book.author}\",\n"
  result += "\"isbn\" : \"#{book.isbn}\",\n"
  result += '}'
 end 

end

然后将Formatter中的代码进行修改,如下所示:

class Formatter 

 def format_book(book)
  before_format
  result = formating(book)
  after_format
  result
 end 

 def before_format
  puts "format begins"
 end 

 def formating(book)
  raise "You should override this method in subclass."
 end 

 def after_format
  puts "format finished"
 end 

end

你会发现format_book方法只有四步,第一步调用before_format,去打印格式转换前的日志。第二步调用formating,处理具体的转换逻辑,但是formating方法中只是raise了一个异常,因为具体的转换的逻辑应该由子类来处理,如果走到了父类的formating方法中,就说明应该出现异常。第三步调用after_format,去打印格式转换后的日志。第四步返回result。
最后调用代码如下:

book = Book.new
book.book_name = "Programming Ruby"
book.pages = 830
book.price = 45
book.author = "Dave Thomas"
book.isbn = "9787121038150"
xmlFormatter = XMLFormatter.new
result = xmlFormatter.format_book(book)
puts result
jsonFormatter = JSONFormatter.new
result = jsonFormatter.format_book(book)
puts result

运行之后,你会发现运行结果和修改前代码的运行结果完全相同。但是使用模板方法之后,代码的可读性有了很大的提高,因为处理格式转换的代码都放到了各自的类当中,而不是全部塞进一个方法中。并且在扩展性上也有了很大的提升,比如你开始感兴趣项目经理说的YAML格式了。
定义类YAMLFormatter继承自Formatter,里面加入处理YAML格式的具体逻辑:

class YAMLFormatter < Formatter 

 def formating(book)
  result = "book_name: #{book.book_name}\n"
  result += "pages: #{book.pages}\n"
  result += "price: #{book.price}\n"
  result += "author: #{book.author}\n"
  result += "isbn: #{book.isbn}\n"
 end 

end

调用代码只需要加入:

yamlFormatter = YAMLFormatter.new
result = yamlFormatter.format_book(book)
puts result

好了,令人头疼的YAML格式就这样被支持了,只需要在调用的时候决定是实例化XMLFormatter,JSONFormatter还是YAMLFormatter,就可以按照相应的规格进行格式转换了。而且整体的代码很有条理,看起来也很舒心。这个时候,你会轻松地向项目经理调侃一句,还有需要支持的格式吗?

实例二

需求:

学生抄题目,做题目

初始代码

# -*- encoding: utf-8 -*-

#学生甲的试卷类
class TestPaperA

 def question1
  puts '杨过得到,后来给了郭靖,炼成倚天剑,屠龙刀的玄铁可能是[] a.球墨铸铁 b.马口铁 c.高速合金钢 d.碳塑纤维 '
  puts '答案:b'
 end

 def question2
  puts '杨过、程英、陆无双铲除了情花,造成了[] a.使这种植物不再害人 b.使一种珍稀物种灭绝 c.破坏了那个生物圈的生态平衡 d.造成该地区沙漠化 '
  puts '答案:a'
 end

 def question3
  puts '蓝凤凰的致使华山师徒、桃谷六仙呕吐不止,如果你是大夫,会给他们开什么药[] a.阿司匹林 b.牛黄解毒片 c.氟酸 d.让他们喝大量的生牛奶 e.以上全不对'
  puts '答案:c'
 end

end
#学生乙的试卷类
class TestPaperB

 def question1
  puts '杨过得到,后来给了郭靖,炼成倚天剑,屠龙刀的玄铁可能是[] a.球墨铸铁 b.马口铁 c.高速合金钢 d.碳塑纤维 '
  puts '答案:d'
 end

 def question2
  puts '杨过、程英、陆无双铲除了情花,造成了[] a.使这种植物不再害人 b.使一种珍稀物种灭绝 c.破坏了那个生物圈的生态平衡 d.造成该地区沙漠化 '
  puts '答案:b'
 end

 def question3
  puts '蓝凤凰的致使华山师徒、桃谷六仙呕吐不止,如果你是大夫,会给他们开什么药[] a.阿司匹林 b.牛黄解毒片 c.氟酸 d.让他们喝大量的生牛奶 e.以上全不对'
  puts '答案:a'
 end

end
puts '学生甲抄的试卷'
student1 = TestPaperA.new
student1.question1
student1.question2
student1.question3

puts '学生乙抄的试卷'
student2 = TestPaperB.new
student2.question1
student2.question2
student2.question3

存在的问题:

TestPaperA和TestPaperB中的代码很多相同的地方,不利于维护,如果需要修改题目的话,就要改两处
改后的代码

# -*- encoding: utf-8 -*-

class TestPaper
 def question1
  puts '杨过得到,后来给了郭靖,炼成倚天剑,屠龙刀的玄铁可能是[] a.球墨铸铁 b.马口铁 c.高速合金钢 d.碳塑纤维 '
 end

 def question2
  puts '杨过、程英、陆无双铲除了情花,造成了[] a.使这种植物不再害人 b.使一种珍稀物种灭绝 c.破坏了那个生物圈的生态平衡 d.造成该地区沙漠化 '
 end

 def question3
  puts '蓝凤凰的致使华山师徒、桃谷六仙呕吐不止,如果你是大夫,会给他们开什么药[] a.阿司匹林 b.牛黄解毒片 c.氟酸 d.让他们喝大量的生牛奶 e.以上全不对'
 end
end

#学生甲的试卷类
class TestPaperA < TestPaper

 def question1
  super
  puts '答案:b'
 end

 def question2
  super
  puts '答案:a'
 end

 def question3
  super
  puts '答案:c'
 end

end
#学生乙的试卷类
class TestPaperB < TestPaper

 def question1
  super
  puts '答案:d'
 end

 def question2
  super
  puts '答案:b'
 end

 def question3
  super
  puts '答案:a'
 end

end
puts '学生甲抄的试卷'
student1 = TestPaperA.new
student1.question1
student1.question2
student1.question3

puts '学生乙抄的试卷'
student2 = TestPaperB.new
student2.question1
student2.question2
student2.question3

可以看出,抽取出来一个公共的试卷类,让甲乙去继承,公用其中的试题。这时再看TestPaperA和TestPaperB,不同的只有答案a、b、c、d不一样,其他的都一样。

# -*- encoding: utf-8 -*-

class TestPaper
 def question1
  puts '杨过得到,后来给了郭靖,炼成倚天剑,屠龙刀的玄铁可能是[] a.球墨铸铁 b.马口铁 c.高速合金钢 d.碳塑纤维 '
  puts "答案:#{answer1}"
 end

 def question2
  puts '杨过、程英、陆无双铲除了情花,造成了[] a.使这种植物不再害人 b.使一种珍稀物种灭绝 c.破坏了那个生物圈的生态平衡 d.造成该地区沙漠化 '
  puts "答案:#{answer2}"
 end

 def question3
  puts '蓝凤凰的致使华山师徒、桃谷六仙呕吐不止,如果你是大夫,会给他们开什么药[] a.阿司匹林 b.牛黄解毒片 c.氟酸 d.让他们喝大量的生牛奶 e.以上全不对'
  puts "答案:#{answer3}"
 end
 def answer1; end
 def answer2; end
 def answer3; end
end

#学生甲的试卷类
class TestPaperA < TestPaper

 def answer1
  'b'
 end

 def answer2
  'a'
 end

 def answer3
  'c'
 end

end
#学生乙的试卷类
class TestPaperB < TestPaper

 def answer1
  'd'
 end

 def answer2
  'b'
 end

 def answer3
  'a'
 end

end
puts '学生甲抄的试卷'
student1 = TestPaperA.new
student1.question1
student1.question2
student1.question3

puts '学生乙抄的试卷'
student2 = TestPaperB.new
student2.question1
student2.question2
student2.question3

这里将TestPaperA和TestPaperB中的答案抽离到了父类中,仅仅保存不同的部分。

父类成为子类的模板,所有重复的代码都应该上升到父类去,而不是让每个子类都去重复。

当我们要完成在某一细节层次一致的过程或一系列步骤,但其个别步骤在更详细层次上的实现可能不同时,我们通常考虑使用模板方法模式来处理。

(0)

相关推荐

  • Ruby设计模式编程中对外观模式的应用实例分析

    何为外观模式? 外观模式为子系统中一组不同的接口提供统一的接口.外观定义了上层接口,通过降低复杂度和隐藏子系统间的通信以及依存关系,让子系统更加易于使用. 比方说子系统中有一组不同的类,其中一些彼此依赖.这让客户端难以使用子系统中的类,因为客户端需要知道每一个类.外观起到整个子系统的入口.有些客户端只需要子系统的某些基本行为,而对子系统的类不做太多定制,外观为这样的客户端提供简化的接口.只有需要从某些子系统的类定制更多行为的客户端,才会关注外观背后的细节. 外观模式:为系统中的一组接口提供一个统

  • 实例解析Ruby设计模式编程中Strategy策略模式的使用

    今天你的leader兴致冲冲地找到你,希望你可以帮他一个小忙,他现在急着要去开会.要帮什么忙呢?你很好奇. 他对你说,当前你们项目的数据库中有一张用户信息表,里面存放了很用户的数据,现在需要完成一个选择性查询用户信息的功能.他说会传递给你一个包含许多用户名的数组,你需要根据这些用户名把他们相应的数据都给查出来. 这个功能很简单的嘛,你爽快地答应了.由于你们项目使用的是MySQL数据库,你很快地写出了如下代码: require 'mysql' class QueryUtil def find_us

  • Ruby设计模式编程之适配器模式实战攻略

    适配器模式 适配器模式可以用于对不同的接口进行包装以及提供统一的接口,或者是让某一个对象看起来像是另一个类型的对象.在静态类型的编程语言里,我们经常使用它去满足类型系统的特点,但是在类似Ruby这样的弱类型编程语言里,我们并不需要这么做.尽管如此,它对于我们来说还是有很多意义的. 当使用第三方类或者库的时候,我们经常从这个例子开始(start out fine): def find_nearest_restaurant(locator) locator.nearest(:restaurant,

  • 实例讲解Ruby使用设计模式中的装饰器模式的方法

    概述        若你从事过面向对象开发,实现给一个类或对象增加行为,使用继承机制,这是所有面向对象语言的一  个基本特性.如果已经存在的一个类缺少某些方法,或者须要给方法添加更多的功能(魅力),你也许会仅仅继承这个类来产生一个新类-这建立在额外的代码上.       通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法.但是这种方法是静态的,用户不能控制增加行为的方式和时机.如果  你希望改变一个已经初始化的对象的行为,你怎么办?或者,你希望继承许多类的行为,改怎么办?前一个,

  • 解析proxy代理模式在Ruby设计模式开发中的运用

    代理模式 Proxy代理模式是一种结构型设计模式,主要解决的问题是:在直接访问对象时带来的问题,比如说:要访问的对象在远程的机器上.在面向对象系统中,有些对象由于某些原因(比如对象创建开销很大,或者某些操作需要安全控制,或者需要进程外的访问),直接访问会给使用者或者系统结构带来很多麻烦,我们可以在访问此对象时加上一个对此对象的访问层.如下图: 比如说C和A不在一个服务器上,A要频繁的调用C,我们可以在A上做一个代理类Proxy,把访问C的工作交给Proxy,这样对于A来说,就好像在直接访问C的对

  • 详解组合模式的结构及其在Ruby设计模式编程中的运用

    定义:也叫合成模式,或者部分-整体模式,主要是用来描述部分与整体的关系,定义,将对象组合成树形结构以表示"部分-整体"的层次结构,使得用户对单个对象和组合对象的使用具有一致性. 类图: 角色说明: Componnent抽象构件角色:定义参加组合对象的共有方法和属性,可以定义一些默认的行为或属性. Leaf叶子构件:叶子对象,其下再也没有其他的分支,也就是遍历的最小单位. Composite树枝构件:树枝对象,它的作用是组合树枝节点和叶子节点形成一个树形结构. 实例: 听说你们公司最近新

  • 深入剖析Ruby设计模式编程中对命令模式的相关使用

    命令模式是对象行为型使用率比较高的设计模式,别名:Action(动作),Transaction(事务) 意图: 将一个请求封装为一个对象,从而使你可对不同的请求进行参数化:对请求排队或记录请求日志,以及支持可取消的操作 这里所谓的"不同的请求"也既意味着请求可能发生的变化,是一个可能扩展的功能点. 动机: 方便扩展 结构: 协作说明:    参与角色:     Command 声明一个接口以用来实现某个操作.     ConcreteCommand 将动作与Reciver对外绑定,通过

  • 详解Ruby设计模式编程中对单例模式的运用

    简介       单例模式是设计模式中最简单的形式之一.这一模式的目的是使得类的一个对象成为系统中的唯一实例.要实现这一点,可以从客户端对其进行实例化开始.因此需要用一种只允许生成对象类的唯一实例的机制,"阻止"所有想要生成对象的访问.使用工厂方法来限制实例化过程.这个方法应该是静态方法(类方法),因为让类的实例去生成另一个唯一实例毫无意义. 要点       显然单例模式的要点有三个:一是某个类只能有一个实例:二是它必须自行创建这个实例:三是它必须自行向整个系统提供这个实例.    

  • Ruby设计模式编程中使用Builder建造者模式的实例

    先来复习一下设计模式的基本概念: 定义 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. 建造者隐藏了该产品是如何组装的,所以若需要改变一个产品的内部表示,只需要重新定一个建造者就可以了. 实用范围 1.当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时. 2.当构造过程必须允许被构造的对象有不同表示时. 角色 在这样的设计模式中,有以下几个角色: 1.builder:为创建一个产品对象的各个部件指定抽象接口. 2.ConcreteBuilder:实现B

  • 实例解析Ruby设计模式开发中对观察者模式的实现

    一般来说,观察者模式的定义应该是这样的:building a clean interface between the source of news that some object has changed and the consumers of that news. 观察者模式在消息的生产者和消费者之间建立了clean interface,这样就使得消息的生产者和消费者之间的耦合是抽象的.被观察者可以不认识任何一个的观察者,它只知道他们都实现了一个共同的接口.由于观察者和被观察者没有紧密的耦合

  • 设计模式中的观察者模式在Ruby编程中的运用实例解析

    观察者模式(有时又被称为发布/订阅模式)是软件设计模式的一种. 在此种模式中,一个目标对象管理所有相依于它的观察者对象,并且在它本身的状态改变时主动发出通知. 这通常透过呼叫各观察者所提供的方法来实现. 实现观察者模式的时候要注意,观察者和被观察对象之间的互动关系不能 体现成类之间的直接调用,否则就将使观察者和被观察对象之间紧密的耦合起来, 从根本上违反面向对象的设计的原则.无论是观察者"观察"观察对象, 还是被观察者将自己的改变"通知"观察者,都不应该直接调用.

  • Ruby使用设计模式中的代理模式与装饰模式的代码实例

    代理模式 需求: 小明让小李替他追小丽(送洋娃娃,送花,送巧克力) 没有代理的代码: # -*- encoding: utf-8 -*- #追求者类 class Pursuit attr_accessor :mm def initialize(mm) @mm = mm end def give_dolls puts "#{mm.name} 送你洋娃娃" end def give_flowers puts "#{mm.name} 送你鲜花" end def give_

  • Ruby中使用设计模式中的简单工厂模式和工厂方法模式

    之前有看过<ruby设计模式>,不过渐渐的都忘记了.现在买了一个大话设计模式,看起来不是那么枯燥,顺便将代码用ruby实现了一下. 简单工厂模式: # -*- encoding: utf-8 -*- #运算类 class Operation attr_accessor :number_a,:number_b def initialize(number_a = nil, number_b = nil) @number_a = number_a @number_b = number_b end d

随机推荐