演化架构与紧急设计: 语言、表达性与设计:第 2 部分
2009-11-05 00:00:00 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閹冣挃闁硅櫕鎹囬垾鏃堝礃椤忎礁浜鹃柨婵嗙凹缁ㄧ粯銇勯幒瀣仾闁靛洤瀚伴獮鍥敍濮f寧鎹囬弻鐔哥瑹閸喖顬堝銈庡亝缁挸鐣烽崡鐐嶆棃鍩€椤掑嫮宓佸┑鐘插绾句粙鏌涚仦鎹愬闁逞屽墰閹虫捇锝炲┑瀣╅柍杞拌兌閻ゅ懐绱撴担鍓插剱妞ゆ垶鐟╁畷銉р偓锝庡枟閻撴洘銇勯幇闈涗簼缂佽埖姘ㄧ槐鎾诲礃閳哄倻顦板┑顔硷工椤嘲鐣烽幒鎴旀瀻闁规惌鍘借ⅵ濠电姷鏁告慨顓㈠磻閹剧粯鈷戞い鎺嗗亾缂佸鏁婚獮鍡涙倷閸濆嫮顔愬┑鐑囩秵閸撴瑦淇婇懖鈺冪<闁归偊鍙庡▓婊堟煛鐏炵硶鍋撻幇浣告倯闁硅偐琛ラ埀顒冨皺閺佹牕鈹戦悙鏉戠仸闁圭ǹ鎽滅划鏃堟偨缁嬭锕傛煕閺囥劌鐏犻柛鎰ㄥ亾婵$偑鍊栭崝锕€顭块埀顒佺箾瀹€濠侀偗婵﹨娅g槐鎺懳熺拠鑼舵暱闂備胶枪濞寸兘寮拠宸殨濠电姵纰嶉弲鎻掝熆鐠虹尨宸ョ€规挸妫濆铏圭磼濡搫顫嶇紓浣风劍閹稿啿鐣烽幋锕€绠婚悹鍥у级瀹撳秴顪冮妶鍡樺鞍缂佸鍨剁粋宥夋倷椤掍礁寮垮┑鈽嗗灣閸樠勭妤e啯鍊垫慨妯煎亾鐎氾拷

本文是本系列文章的第 2 部分,旨在演示计算机语言的表达性(允许您专注于本质,而不是形式)对于紧急设计的重要作用。意图(intent)与结果(result)之间的分歧对于许多年代久远的语言(包括 Java™ 语言)来说都是一个通病,从而为问题解决工作添加了不必要的形式。表达性更好的语言可以帮助开发人员更加轻松地发现惯用模式,因为代码中包含的无用信息更少。表达性是 Groovy 和 Scala 等现代语言的特征;年代久远但表达性较好的语言包括 Ruby(其中,JRuby 是一种 JVM 变体);其他表达性较好的语言还包括经过翻新的 Clojure,以及基于 JVM 的现代 Lisp。在本文中,我将继续 第 1 部分 中的演示 — 使用表达性更好的语言实现设计模式 一书中的传统四人组模式。
修饰符模式
四人组的书籍将修饰符模式定义为:
将额外的责任动态赋予某个对象。修饰符提供了另外一种灵活的用于扩展功能的继承方法。
如果您曾经使用过 java.io.* 包,则应该对修饰符模式有所了解。显然,I/O 库的设计者们阅读了四人组书籍的修饰符部分,并领悟了其核心意义!首先,我将演示修饰符模式在 Groovy 中的传统实现,然后再在后续示例中提高它的动态性。
传统的修饰符
清单 1 显示了一个 Logger 类,以及与该类相关的一些修饰符(TimeStampingLogger 和 UpperLogger),所有代码均在 Groovy 中实现:
清单 1. Logger 和两个修饰符
class Logger {
def log(String message) {
println message
}
}
class TimeStampingLogger extends Logger {
private Logger logger
TimeStampingLogger(logger) {
this.logger = logger
}
def log(String message) {
def now = Calendar.instance
logger.log("$now.time: $message")
}
}
class UpperLogger extends Logger {
private Logger logger
UpperLogger(logger) {
this.logger = logger
}
def log(String message) {
logger.log(message.toUpperCase())
}
}
更多精彩
赞助商链接