摘要:使用匿名内部类是最经典的使用方法之一。可以通过表达式替代匿名内部类,简化设计。
OO makes code understandable by encapsulating moving parting, but FP makes code understandable by minimizing moving parts. -Michael Feathers
刘光聪,程序员,敏捷教练,开源软件爱好者,具有多年大型遗留系统的重构经验,对OO,FP,DSL等领域具有浓厚的兴趣。
GitHub: https://github.com/horance-liu
Email: horance@outlook.com
Product Repository First Attempt: The Worst Implement需求1:在仓库中查找所有颜色为红色的产品
public ArrayList findAllRedProducts(ArrayList repo) { ArrayList result = new ArrayList(); for (int i=0; i指令式(Imperative)
缺乏编译时类型安全性检查
实现类型
硬编码
重复设计
Second Attempt: Using for-eachpublic ListThird Attempt: ParameterizingfindAllRedProducts(List repo) { List result = new ArrayList<>(); for (Product p : repo) { if (p.getColor() == Color.RED) { result.add(p); } } return result; } 需求2:在仓库中查找所有颜色为绿色的产品
Copy-Paste是大部分程序员最容易犯的毛病,为此引入了大量的重复代码。
public ListfindAllGreenProducts(List repo) { List result = new ArrayList<>(); for (Product p : repo) { if (p.getColor() == Color.GREEN) { result.add(p); } } return result; } 为了消灭Hard Code和重复代码,得到可重用的代码,可以引入简单的参数化设计。
public ListForth Attempt: Parameterizing with Every Attribute You Can Think OffindProductsByColor(List repo, Color color) { List result = new ArrayList<>(); for (Product p : repo) { if (p.getColor() == color) { result.add(p); } } return result; } 需求3:查找所有重量小于10的所有产品
大部分程序员依然会使用Copy-Paste解决这个问题,拒绝Copy-Paste的陋习,最具实效的一个办法就是把Copy-Paste的快捷键失效,当每次尝试Copy-Paste时提醒自己做更好的设计。
public ListfindProductsBelowWeight(List repo, int weight) { List result = new ArrayList<>(); for (Product p : repo) { if (p.getWeight() < weight) { result.add(p); } } return result; } 为了消除两者重复的代码,通过简单的参数化往往不能完美解决这类问题,相反会引入额外的复杂度。
public ListfindProducts(List repo, Color color, int weight, boolean flag) { List result = new ArrayList<>(); for (Product p : repo) { if ((flag && p.getColor() == color) || (!flag && p.getWeight() < weight)) { result.add(p); } } return result; } 日常工作中这样的实现手法非常普遍,函数的参数列表随着需求增加不断增加,函数逻辑承担的职责越来越多,逻辑也变得越来越难以控制。
Firth Attempt: Abstracting over Criteria为此需要抽取出隐藏的概念,使其遍历的算法与查找的标准能够独立地变化,将行为参数化。
public interface ProductSpec { boolean satisfy(Product product); }此刻findProducts的算法逻辑得到封闭。
public ListfindProducts(List repo, ProductSpec spec) { List result = new ArrayList<>(); for (Product p : repo) { if (spec.satisfy(p)) { result.add(p); } } return result; } 通过可复用的Functor来封装各种变化,让变化的因素控制在最小的范围内。
public class ColorSpec implements ProductSpec { private Color color; public ColorSpec(Color color) { this.color = color; } @Override public boolean satisfy(Product product) { return product.getColor() == color; } }public class BelowWeightSpec implements ProductSpec { private int limit; public BelowWeightSpec(int limit) { this.limit = limit; } @Override public boolean satisfy(Product product) { return product.getWeight() < limit; } }用户的接口也变得简单多了,而且富有表现力。
Listproducts = findProducts(repo, new ColorSpec(RED)); 这是经典的OO设计,如果熟悉设计模式的读者对此已经习以为常了。设计模式是好东西,但常常被人依葫芦画瓢,死板照抄,甚至被滥用。事实上,引入或去除设计模式是一个很自然的过程。与大师们交流,问究此处为何引入设计模式,得到的答案:直觉。忘记所有设计模式吧,管它是不是模式,如果设计是简单的,它这就是模式。
至此,代码另外还有一个明显的坏味道,ColorSpec和BelowWeightSpec都需要继承ProductSpec,都需要定义一个构造函数和一个私有的字段,并重写satisfy方法,这是一种典型的重复现象:重复型结构。
因Java缺乏闭包的支持,程序员不得不承受这样的烦恼,但此刻暂时不关心,继续前进。
Sixth Attempt: Composite Criteria需求4:查找所有颜色为红色或者绿色,并且重量小于10的产品
按照既有的代码结构,往往易于设计出类似ColorAndBelowWeightSpec的实现。
public class ColorAndBelowWeightSpec implements ProductSpec { private Color color1; private Color color2; private int limit; public ColorAndBelowWeightSpec(Color color1, Color color2, int limit) { this.color1 = color1; this.color2 = color2; this.limit = limit; } @Override public boolean satisfy(Product p) { return (p.getColor() == color1 || p.getColor() == color2) && (p.getWeight() < limit); } }存在两个明显的坏味道:
类名中包含And往往是违背单一职责的信号灯
ColorAndBelowWeightSpec的实现与ColorSpec,BelowWeightSpec之间存在明显的重复
此刻,需要寻找更本质的抽象来表达设计,引入and/or的语义模型。
Composite Spec: AndSpec, OrSpec
Atomic Spec:ColorSpec, BeblowWeightSpec
publc class AndSpec implements ProductSpec { private Listspecs = new ArrayList<>(); public AndSpec(ProductSpec... specs) { this.specs.addAll(Arrays.asList(specs)); } @Override public boolean satisfy(Product p) { for (ProductSpec spec : specs) { if (!spec.satisfy(p)) return false; } return true; } } publc class OrSpec implements ProductSpec { private Listspecs = new ArrayList<>(); public OrSpec(ProductSpec... specs) { this.specs.addAll(Arrays.asList(specs)); } @Override public boolean satisfy(Product p) { for (ProductSpec spec : specs) { if (spec.satisfy(p)) return true; } return false; } ![clipboard.png](/img/bVtn06) } 可以通过AndSpec组合ColorSpec, BelowWeightSpec来实现需求,简单漂亮,并且富有表达力。
Listproducts = findProducts(repo, new AndSpec( new OrSpec(new ColorSpec(RED), new ColorSpec(Greeen)), new BelowWeightSpec(10)); 此时设计存在两个严重的坏味道:
AndSpec与OrSpec存在明显的代码重复
大堆的new让人眼花缭乱
Seventh Attempt: Extract Parent先尝试消除AndSpec与OrSpec存在的代码重复,OO设计的第一个直觉就是通过抽取基类。
class CombinableSpec implements ProductSpec { private Listspecs = new ArrayList<>(); private boolean shortcut; protected CombinableSpec(List specs, boolean shortcut) { this.specs.addAll(specs); this.shortcut = shortcut; } @Override public boolean satisfy(Product p) { for (ProductSpec spec : specs) { if (spec.satisfy(p) == shortcut) return shortcut; } return !shortcut; } } 通过参数化配置,复用CombinableSpec的实现。
publc class AndSpec extends CombinableSpec { public AndSpec(ProductSpec... specs) { super(Arrays.asList(specs), false); } }publc class OrSpec extends CombinableSpec { public OrSpec(ProductSpec... specs) { super(Arrays.asList(specs), true); } }如何评判boolean接口的使用呢?在不损伤可理解性的前提下,为了消除重复的设计是值得推荐的。boolean接口的可理解性关键依赖于调用点与函数接口之间的距离,如果在同一个文件,同一个类,并能在一个页面显示的,是完全可以接受的。
Eighth Attempt: Decorate Criteria需求5:查找所有颜色为不是红色的产品
publc class NotSpec implements ProductSpec { private ProductSpec spec; public NotSpec(ProductSpec spec) { this.spec = spec; } @Override public boolean satisfy(Product p) { return !spec.satisfy(p); } }NotSpec是一种修饰了的ProductSpec,同时也使得用户的接口也变得更加人性化了。
ListNinth Attempt: Using Static Factory to DSLproducts = findProducts(repo, new NotSpec(new ColorSpec(RED))); 之前遗留了一个问题,一大堆眼花缭乱的new使得代码失去了部分的可读性。
Listproducts = findProducts(repo, new AndSpec( new OrSpec(new ColorSpec(RED), new ColorSpec(Greeen)), new BelowWeightSpec(10)); 可以引入DSL改善程序的可读性,让代码更具表达力。
Listproducts = findProducts(repo, and(or(color(RED), color(GREEN)), belowWeight(10))); 上述的DSL可以使用static factory的设计手段简单实现。按照惯例,可以建立类似于ProductSpecs的工具类,将这些工厂方法搬迁到工具类中去。
接口与对应工具类的对称性设计在Java社区中应用非常广泛,例如标准库中的java.util.Collection/java.util.Collections的设计。
public interface ProductSpec { boolean satisfy(Product p); }public final class ProductSpecs { public static ProductSpec color(final Color color) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return p.getColor() == color; } }; } public static ProductSpec belowWeight(final int limit) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return p.getWeight() < limit; } }; } public static ProductSpec and(ProductSpec... specs) { return new CombinableSpec(Arrays.asList(specs), false); } public static ProductSpec or(ProductSpec... specs) { return new CombinableSpec(Arrays.asList(specs), true); } public static ProductSpec not(final ProductSpec spec) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return !spec.satisfy(p); } }; } private ProductSpecs() { throw new AssertionError("no instances"); } }此外,使用匿名内部类,可以得到意外的惊喜。通过有限地引入闭包的概念,从而避免了类似Firth Attempt/Sixth Attempt的设计中引入多余的构造函数和成员变量的复杂度,从而消除了部分的结构性重复的坏味道。
当然,要让这些static factory可见,需要import static导入这些方法。
import static practical.programming.overview.ProductSpec.*; ListTenth Attempt: Moving Static Factory into Interfaceproducts = findProducts(repo, not(and(color(RED), belowWeight(10))); 使用Java8可以将这些工厂方法直接搬迁到ProductSpec的接口中去,这样做至少得到两个好处。
可以删除ProductSpecs的工具类
使的接口和静态方法(尤其静态工厂方法)关系更加紧密
Java8并没有因为comparing等静态工厂方法的增强而建立Comparators的工具类,而是直接将它们集成在Comparator的接口中,这是自Java8之后思维的一个新的转变(Comparator.comparing的实现留作作业巩固今天所学知识)。
对于本例,可以将ProductSpecs删除,将所有静态工厂方法搬迁到ProductSpec中去。
public interface ProductSpec { boolean satisfy(Product p); static ProductSpec color(Color color) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return p.getColor() == color; } }; } static ProductSpec belowWeight(int limit) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return p.getWeight() < limit; } }; } static ProductSpec and(ProductSpec... specs) { return new CombinableSpec(Arrays.asList(specs), false); } static ProductSpec or(ProductSpec... specs) { return new CombinableSpec(Arrays.asList(specs), true); } static ProductSpec not(ProductSpec spec) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return !spec.satisfy(p); } }; } }Eleventh Attempt: Using Null Object需求6:无条件过滤掉或不过滤查找所有产品
import static practical.programming.overview.ProductSpec.*; Listproducts = findProducts(repo, always(false)); public interface ProductSpec { boolean satisfy(Product p); static ProductSpec always(boolean bool) { return new ProductSpec() { @Override public boolean satisfy(Product p) { return bool; } }; } }至此,ProductSpec存在如下一些类型:
Composite Specs: and, or
Decorator Specs: not
Atomic Specs: always, color, beblowWeight
Twelfth Attempt: Using Lambda ExpressionJava8可以使用Lambda表达式改善设计,增强表达力。
Listproducts = findProducts(repo, (Product p) -> p.getColor() == RED); 通过类型推演,可以进一步省略Labmda表达式中参数的类型信息。
Listproducts = findProducts(repo, p -> p.getColor() == RED); 当然,你可以通过提取static factory,构造DSL复用这些Lambda表达式。
@FunctionalInterface public interface ProductSpec { boolean satisfy(Product p); static ProductSpec color(Color color) { return p -> p.getColor() == color; } static ProductSpec weightBelow(int limit) { return p -> p.getWeight() < limit; } }Listproducts = findProducts(repo, color(RED)); 其中,@FunctionalInterface注解标注了ProductSpec是一个函数式接口,其抽象方法boolean satisfy(Product p)的原型描述了lambda表达式的Function Descriptor。
Thirteenth Attempt: Chaining Speciafications遗留了一个问题: 如何替换匿名内部类,使用lambda实现 and/or/not/always的语义?
@FunctionalInterface public interface ProductSpec { boolean satisfy(Product p); default ProductSpec negate() { return p -> !satisfy(p); } default ProductSpec and(ProductSpec other) { return (p) -> satisfy(p) && other.satisfy(p); } default ProductSpec or(ProductSpec other) { return (p) -> satisfy(p) || other.satisfy(p); } static ProductSpec always(boolean bool) { return p -> bool; } static ProductSpec color(Color color) { return p -> p.getColor() == color; } static ProductSpec belowWeight(int limit) { return p -> p.getWeight() < limit; } }这里引入了Java8一个重要的设计工具:default method,简单漂亮,并巧妙地实现DSL的设计,用户接口变得更加流畅、友好。
Listproducts = findProducts(repo, color(RED).and(belowWeight(10))); Java8支持default method,扩展了interface原来的语义,从而隐式地支持了组合式设计,使的OO的设计更加完善和强大。
Fourteenth attempt: Using Method Reference需求7:查找所有伪劣的产品
Listproducts = findProducts(repo, p -> p.fake()); 可以使用Method Reference进一步改善lambda的表达力。
ListFifteenth attempt: Abstracting over Typeproducts = findProducts(repo, Product::fake); 泛化类型信息,让算法更具有通用性,并进一步增强代码的可复用性。
public staticList filter(List list, Predicate p) { List result = new ArrayList<>(); for (T e : list) { if (p.test(e)) { result.add(e); } } return result; } 这样的实现存在一个明显的问题:泛型参数缺乏型变的能力。通过对泛型参数实施无限定类型通配符的修饰,从而使的算法实现更加具有弹性和通用性。
public staticSixteenth: Maximize ReusabilityList filter(List extends T> list, Predicate super T> p) { List result = new ArrayList<>(); for (T e : list) { if (p.test(e)) { result.add(e); } } return result; } and, or, not, always在代数系统中具有稳定的抽象,为此需要进一步重构,以便最大化代码的可复用性。这样当需要建立诸如NumberSpec, FruitSpec时无需重复地再写一遍and, or, not, always的实现。
为此,建立更为抽象的Predicate的概念,并将通用的、抽象的negate, and, or, always搬迁到Predicate中去,使其具有更大的可复用性。
@FunctionalInterface public interface Predicate{ boolean test(T t); default Predicate negate() { return p -> !satisfy(p); } default Predicate and(Predicate super T> other) { return p -> satisfy(p) && other.satisfy(p); } default Predicate or(Predicate super T> other) { return p -> satisfy(p) || other.satisfy(p); } static Predicate always(boolean bool) { return p -> bool; } } 同时,将领域内的color, belowWeight等原子放回ProductSpecs工具类中去(因为不存在ProductSpec的接口了),让领域内的lambda表达式具有更大的复用性。
public final class ProductSpecs { public static Predicatecolor(Color color) { return p -> p.getColor() == color; } public static Predicate belowWeight(int limit) { return p -> p.getWeight() < limit; } private ProductSpecs() { throw new AssertionError("no instances"); } } 至此,可复用的基础设施便从领域中剥离出来,使其具有更高度的可重用性。
Seventeenth Attempt: Using Stream APIJava8可以使用集合库的Stream复用代码。
import static java.util.stream.Collectors.toList; repo.stream() .filter(p -> p.getColor() == RED && p.getPrice() < 10) .collect(toList());如果要支持并发,则可以构建parallelStream。
import static java.util.stream.Collectors.toList; repo.parallelStream() .filter(p -> p.getColor() == RED && p.getPrice() < 10) .collect(toList());集合类通过stream, parallelStream工厂方法创建Stream之后,其操作可分为2种基本类型:
Transformation:其返回值为Stream类型
Action:其返回值不是Stream类型
通过Stream的机制,实现了集合类的惰性求值,直至Action才真正地开始执行计算。Transformation从某种意义上,可以看成是Stream的Builder,直至Action启动执行。
Eighteenth attempt: Replace Java with ScalaScala语言是一门跨越OO和FP的一个混血儿,可以方便地与Java进行互操作。在Scala中,函数作为一等公民,使用Lambda是一个很自然的过程。当你熟悉了Scala,我相信你绝对会放弃Java,放弃Java8,犹如作者本人一样。
repo.filter(p => p.color == RED && p.weight < 10)遗留了三个问题:
如何复用lambda表达式?
如何实现 and/or/not的语义?
如何实现 always的语义?
Nineteenth Attempt: Abstracting Control Structure引入静态工厂方法及其操作符重载的机制构造内部DSL。
import ProductSpec._ repo.filter(color(RED) && belowWeight(10))object ProductSpec { def color(color: Color) = ??? def bebowWeight(limit: Int) = ??? }如何替换实现???,并让其具有&&, ||, !的语义呢?
object ProductSpec { def color(color: Color) = new Predicate((p: Product) => p.color == color) def bebowWeight(limit: Int) = new Predicate((p: Product) => p.weight < limit) }Predicate一个扩展匿名函数A => Boolean的子类,其中,从面向对象的角度看,A => Boolean的类型为Function[A, Boolean]。
class Predicate[A](pred: A => Boolean) extends (A => Boolean) { override def apply(a: A) = pred(a) def &&(that: A => Boolean) = new Predicate[A](x => pred(x) && that(x)) def ||(that: A => Boolean) = new Predicate[A](x => pred(x) || that(x)) def unary_! = new Predicate[A](x => !pred(x)) }其中!是一个一元操作符。
Twentieth Attempt: Using Companion Objectalways静态工厂方法,可以搬迁到Predicate的伴生对象中去。
object Predicate { def always[A](bool: Boolean) = new Predicate[A](_ => bool) }Predicate的设计既使用了OO的特性,又引入了FP的思维,Scala使其两者如此和谐、完美,简直不可思议。
Conclusion世界是多样性的,计算机工业也不仅仅只存在一种方法论。在我的哲学观里,OO和FP之间并不矛盾,而是一个和谐的,相互补充的统一体。
除了C++语言之外,使得我最偏爱Scala,多范式,一个问题存在多种解决方案等等思维习惯,给了程序员最灵活、最自由的空间。
Review Comprator.comparing以标准库Collections.sort,及其Comparator在Java8中的增强,及其Comparator.comparing的泛型定义复习今天所学知识。
public final class Collectins { private Collectins() { } public staticvoid sort(List list, Comparator super T> c) { list.sort(c); } } 使用匿名内部类是Collectins.sort最经典的使用方法之一。
Collections.sort(products, new Comparator() { @Override public int compare(Product p1, Product p2) { return p1.getName().compareTo(p2.getName); } });可以通过lambda表达式替代匿名内部类,简化设计。
Collections.sort(products, (Product p1, Product p2) -> p1.getName().compareTo(p2.getName));通过类型推演,但依然得到编译器类型安全的保护。
Collections.sort(products, (p1, p2) -> p1.getName().compareTo(p2.getName));通过Comprator.compring的静态工厂方法,改善表达力。
Collections.sort(persons, comparing(p -> p.getName()))通过Function Reference的机制,进一步改善表达力。
Collections.sort(persons, comparing(Person::getName()))其中,Comprator.compring的实现为:
@FunctionalInterface public interface Comparator{ int compare(T o1, T o2); static > Comparator comparing(Function super T, ? extends U> extractor) { return (c1, c2) -> extractor.apply(c1).compareTo(extractor.apply(c2)); } }
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/65592.html
摘要:函数式编程,一看这个词,简直就是学院派的典范。所以这期周刊,我们就重点引入的函数式编程,浅入浅出,一窥函数式编程的思想,可能让你对编程语言的理解更加融会贯通一些。但从根本上来说,函数式编程就是关于如使用通用的可复用函数进行组合编程。 showImg(https://segmentfault.com/img/bVGQuc); 函数式编程(Functional Programming),一...
摘要:不过因为各个平台互相挖人的关系,导致关注的一些主播分散到了各个直播平台,来回切换有点麻烦,所以萌生了做一个视频聚合站的想法。后续我们会对这三个部分的功能做逐一展开说明。正则处理要求比较高,但是几乎能应对所有的情况,属于大杀器。 前言 作为一个炉石传说玩家,经常有事没事开着直播网站看看大神们的精彩表演。不过因为各个平台互相挖人的关系,导致关注的一些主播分散到了各个直播平台,来回切换有点麻...
摘要:例日本的企业由于种种原因把制作放在本土,这样产品需要远洋运输到客户手中。让生产过程流动起来,减少部门之间的浪费。尽善尽美快速反馈,积极改进。 精益思想Lean thinking 浪费专指消耗了资源而不创造价值的一切人类活动 需要纠正的错误 生产了无需求的产品 由此造成的库存和积压 不必要的工序 员工的盲目走动 货物从一地到另一地的盲目搬运 由于上道工序发送传递不及时,使做下一道工序的...
摘要:关于中顺序的基本操作关于中顺序的基本操作写在前面最近研究一下中的顺序,在网络上找了一会儿,发现少有详细的介绍,顾此在此处说说顺序,才学疏浅,如有不对,望赐教。上述代码中标记位置中,返回下一次操作时的位置。关于JAVA中顺序IO的基本操作 写在前面 最近研究一下JAVA中的顺序IO,在网络上找了一会儿,发现少有详细的介绍,顾此在此处说说顺序IO,才学疏浅,如有不对,望赐...
书籍完整目录 4.1 react 代码规范 showImg(https://segmentfault.com/img/bVyE9m); 关于 基础规范 组件结构 命名规范 jsx 书写规范 eslint-plugin-react 关于 在代码的设计上,每个团队可能都有一定的代码规范和模式,好的代码规范能够提高代码的可读性便于协作沟通,好的模式能够上层设计上避免不必要的 bug 出现。本节会参考...
阅读 1240·2021-11-22 13:54
阅读 1425·2021-11-22 09:34
阅读 2698·2021-11-22 09:34
阅读 4008·2021-10-13 09:39
阅读 3342·2019-08-26 11:52
阅读 3361·2019-08-26 11:50
阅读 1529·2019-08-26 10:56
阅读 1913·2019-08-26 10:44