开闭与接口隔离答案

【问题标题】：Open Closed and Interface Segregation开闭与接口隔离
【发布时间】：2017-12-18 03:23:05
【问题描述】：

我正在编写一个基本上读取文本文件（表格格式）并检查文件是否包含预期数据类型的代码。为此，我写了以下课程。

示例文件是这样的。

name    age
abc     20
xyz     vf
aaa     22

我有 JSON 文件，上面写着，哪个列应该包含什么？

{
    filename:"test.txt",
    cols:{
            name:string,
            age: int
    }

}

JSON 文件包含每一行的 DataType，所以我知道会发生什么？

以下代码正常工作。但是，该代码似乎违反了开放封闭和接口隔离的原则。

public class DataValidation {

    public boolean isInt(String value) {
        try {
            Integer.parseInt(value);
            return true;
        } catch (NumberFormatException ne) {
            return false;
        }
    }


    public boolean isFloat(String value) {
        try {
            Float.parseFloat(value);
            return true;
        } catch (NumberFormatException ne) {
            return false;
        }
    }

}

所以我正在考虑 Refector 如下所述的代码。但是，想知道我会得到什么优势，有没有更好的方法？

public interface DataValidation {

    boolean validate(String value);
}

public class IntValidator implements DataValidation {
    public boolean validate(String value) {
        try{
            Integer.parseInt(value);
            return true;
        }catch (NumberFormatException ne){
            return false;
        }
    }
}

【问题讨论】：

Em.... 你想摆脱 JSON 字段的声明类型还是什么？请提供示例。
不确定我是否理解您的最后一个问题。你能再解释一下吗？
您的数据类型是否仅限于原始数据类型或更多？
@Green_Wizard 我试图了解是否有更好的方法来重新编码代码。但是我有一个替代解决方案，我仍然需要编写一个逻辑来匹配每个单元格调用哪个函数。
@Gholamali-Irani 是的，所有数据类型都仅限于原始数据类型。

标签： java oop solid-principles

【解决方案1】：

开闭原则 (OCP) 的基本定义：（Meyer 1988）
开放/封闭原则指出“软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭”；也就是说，这样的实体可以在不修改其源代码的情况下扩展其行为。 see Reference

BUT：另一方面，this reference 中的 Uncle Bob 提供了一些关于 OCP 含义的说明。（我在下面使用它们）

首先：在我看来，你的班级 (DataValidation)没有冲突 开闭原则。

您的班级只需检查原始数据类型。（正如你在评论中回答我的问题）。 Java 中只有 8 种原始数据类型。 这个数字以后不会变。所以如果你把这8个方法都放在一个类里，以后就不会对数据类型进行任何扩展或修改了。
另一方面，OCP 是在不更改旧代码的情况下添加新的源代码。因此，如果 Java 添加新的数据类型，您可以轻松添加方法，而无需修改其他代码部分。

因此，我认为你的班级不够大，不能违反开闭原则。

其次：使用接口隔离原则（ISP）
要使用 ISP，我们需要一些先决条件。我们的系统（或类）的一部分之间应该有一些依赖关系。我们应该需要依赖管理来管理系统的某些部分，并且我们有意识地决定系统的每个部分可以依赖什么。 please read this reference in-depth

我认为您的类只是一个 Checker 类，没有任何状态（属性或字段）。所以没有任何理由使用 ISP。

总结：使用所有面向对象的原则和启发式方法（如 SOLID），应该有助于我们降低复杂性。在您的项目中，无需使用它们。

为您的问题提供解决方案
您可以将enum DataTypes {boolean, char, _etc_} 用于原始数据类型，并仅使用DataType getDataType(String S) 之类的一种方法来获取给定String 的类型为enum。但是您的方法 (DataValidation class) 也足够好。

【讨论】：

【解决方案2】：

Gholamali-Irani 提供了很好的答案，但我想添加一些我自己对您的主题的看法：

首先，几乎每一个最佳实践、范式等都试图提高可维护性、可测试性和可扩展性的程度。你真的需要它们吗？添加一些自定义和复杂类型的概率有多大？如果它非常低，那么您的第一个变体可能足以完成您的任务（不适用于一般的验证任务，仅适用于您的任务）。

其次，很大程度上取决于您如何使用它。你没有展示你是如何使用所有这些方法/类/接口的。 “仆人”代码可能非常好，它可以是世界上最干净的代码，但谁在乎它是否使用不正确或很难使用？

【讨论】：