oop 类和对象的_实用程序类的OOP替代

oop 类和对象的

实用程序类（也称为帮助程序类）是仅具有静态方法且不封装状态的“结构”。 StringUtils ， IOUtils ， FileUtils从Apache的共享 ; Guava的 Iterables和Iterators以及JDK7的Files是实用程序类的完美示例。

这种设计思想在Java世界（以及C＃，Ruby等）中非常流行，因为实用程序类提供了在各处使用的通用功能。

在这里，我们要遵循DRY原则并避免重复。因此，我们将通用代码块放入实用程序类中，并在必要时重用它们：

// This is a terrible design, don't reuse
public class NumberUtils {public static int max(int a, int b) {return a > b ? a : b;}
}

确实，这是一种非常方便的技术！

实用程序类是邪恶的

但是，在面向对象的世界中，实用程序类被认为是非常不好的实践（有些甚至可能说“可怕”）。

关于这个主题已经有很多讨论。仅举几例： Helper Classes Evil？尼克·马利克（Nick Malik）撰写的《为什么西蒙·哈特（Simon Hart）的助手，单身人士和实用程序类大多不好，沃德元帅避免使用实用程序类，杀死实用程序类！由Dhaval Dalal撰写，帮助类是 Rob Bagby的代码气味。

此外，在StackExchange上还有一些关于实用程序类的问题：如果“实用程序”类是邪恶的，那么我应该将通用代码放在哪里？，实用程序类是邪恶的。

他们所有论点的简要总结是，实用程序类不是正确的对象。因此，它们不适合面向对象的世界。它们从过程编程中继承而来，主要是因为大多数方法都用于那时的功能分解范例。

假设您同意这些参数并且想停止使用实用程序类，我将通过示例展示如何用适当的对象替换这些生物。

程序示例

举例来说，假设您要读取一个文本文件，将其拆分为几行，修剪每一行，然后将结果保存到另一个文件中。这可以通过Apache Commons的FileUtils完成：

void transform(File in, File out) {Collection<String> src = FileUtils.readLines(in, "UTF-8");Collection<String> dest = new ArrayList<>(src.size());for (String line : src) {dest.add(line.trim());}FileUtils.writeLines(out, dest, "UTF-8");
}

上面的代码看起来很干净；但是，这是过程编程，而不是面向对象的。我们正在处理数据（字节和位），并明确指示计算机从何处检索数据，然后在何处将其放置在每一行代码中。我们正在定义执行程序 。

面向对象的替代

在面向对象的范例，我们应该实例和撰写的对象，从而让他们管理数据时，他们如何渴望。与其调用补充静态函数，不如创建能够公开我们正在寻求的行为的对象：

public class Max implements Number {private final int a;private final int b;public Max(int x, int y) {this.a = x;this.b = y;}@Overridepublic int intValue() {return this.a > this.b ? this.a : this.b;}
}

此过程调用：

int max = NumberUtils.max(10, 5);

将成为面向对象的：

int max = new Max(10, 5).intValue();

土豆土豆并不是的; 只是继续阅读...

对象而不是数据结构

这就是我如何设计与上述相同的文件转换功能，但是是以面向对象的方式进行的：

void transform(File in, File out) {Collection<String> src = new Trimmed(new FileLines(new UnicodeFile(in)));Collection<String> dest = new FileLines(new UnicodeFile(out));dest.addAll(src);
}

FileLines实现Collection<String>并封装所有文件读取和写入操作。 FileLines实例的行为与字符串的集合完全相同，并且隐藏了所有I / O操作。当我们迭代它时—正在读取一个文件。当我们addAll()时—正在写入文件。

Trimmed还实现了Collection<String>并封装了一个字符串集合（ Decorator模式）。每次检索下一行时，都会对其进行修剪。

所有服用参与片断类是相当小： Trimmed ， FileLines和UnicodeFile 。他们每个人都对自己的单一功能负责，因此完全遵循单一责任原则。

在我们这方面，作为库的用户，这可能并不那么重要，但是对于他们的开发人员而言，这势在必行。与在80多个方法和3000行实用程序类FileUtils使用readLines()方法相比，开发，维护和测试FileLines类要容易得多。认真地看一下其源代码。

面向对象的方法使延迟执行成为可能。 in需要输入数据之前，不会读取in文件。如果我们不能开out由于一些I / O错误，第一个文件甚至不能触及。整个节目只有在我们调用addAll()之后才开始。

除了最后一个片段外，第二个片段中的所有行都实例化并将较小的对象组合为较大的对象。该对象组合对于CPU而言相当便宜，因为它不会引起任何数据转换。

除此之外，很明显第二个脚本在O（1）空间中运行，而第一个脚本在O（n）中运行。这是我们对第一个脚本中的数据采用过程方法的结果。

在面向对象的世界中，没有数据。只有对象及其行为！

您可能还会发现以下有趣的帖子：

为什么NULL是错误的？
避免字符串串联
对象应该是不可变的
Java代码中的典型错误

翻译自: https://www.javacodegeeks.com/2014/09/oop-alternative-to-utility-classes.html

oop 类和对象的