【问题标题】:Correct OOP approach for creating an object from a string从字符串创建对象的正确 OOP 方法
【发布时间】:2014-01-04 01:24:15
【问题描述】:

我正在阅读一些文本文件来创建对象。哪个类应该根据 OOP 原则处理文本文件?

我的 GUI 对象有一个方法来绘制表格并用数据填充它。此数据要么从 HTML 页面解析,要么从缓存的文本文件中读取。我可以想到两种方法来处理这个问题,我想知道哪种方法更好。

选项 1:

public void drawSchedule()
    {
        try
        {
            if (CacheManager.hasData("schedule")) //this is not the complete logic, but enough for this post
            {
                String cacheString = CacheManager.readData(this, "schedule");

                Schedule schedule = new Schedule(cacheString);
            }
            else
            {
                //read data from HTML page
            }
        catch (IOException e)
        {
            //generic error handling
            e.printStackTrace();
        }
    }

选项 2:

public void drawSchedule()
{
    try
    {
        if (CacheManager.hasData("schedule")) //this is not the complete logic, but enough for this post
        {
            String cacheString = CacheManager.readData(this, "schedule");

            //parse data here so we end up with a bunch of variables

            //courseList would be an ArrayList of Courses, if it makes any difference
            Schedule schedule = new Schedule(firstDay, courseList);
        }
        else
        {
            //Read data from HTML page
        }
    catch (IOException e)
    {
        //generic error handling
        e.printStackTrace();
    }
}

【问题讨论】:

  • parsing 在选项 1 中的表现如何?
  • @PM77-1 在选项 1 中,Schedule 的构造函数将解析字符串。
  • 在不知道细节的情况下,我只从封装(和解耦)的角度来选择 选项 1

标签: java android oop


【解决方案1】:

老实说,这两种方法都是有效的,并且很大程度上取决于数据的性质和对象的使用方式。事实上,将问题标记为主要基于意见几乎很诱人!

如果解析非常具体到这些文本文件,并且如果 Schedule 被用于许多其他地方,那么将解析代码分开可能会更好。

另一方面,如果该解析可以在多个地方使用,那么将其放在Schedule 中是有意义的。想想不要重复自己和封装。您希望代码在任何有用的地方都可见,但在其他任何地方都不可见,并且您只想拥有该代码一次。

Java 库中的示例包括诸如 Date 类之类的东西,它有一些通用构造函数,但还有一个 DateFormatclass 能够完成所有工作来处理 DateString.

【讨论】:

    【解决方案2】:

    我投票支持选项 1。

    Schedule 应该知道如何从String 或 HTML 页面创建自己。这些逻辑都不应该在drawSchedule 中,正如人们可能猜到的那样,它的工作应该只是绘制Schedule。您想将构建Schedule 的关注点与绘制它分开。

    既然这不会太难做,你不妨去做。但要小心过早地变得过于优雅。正如 Bob Martin 在Agile Software Development, Principles, Patterns, and Practices 中建议的“拿第一颗子弹”和 Nathan Marz 在“suffering-oriented programming”中建议的那样,不要这么快就变得“漂亮”。让一切先行;然后仅当不这样做的痛苦使其值得时才重构为更优雅的方法。

    【讨论】:

    • 还有一个事实是我在创建缓存文件时在Schedule 中生成了cacheString。所以解析永远不应该取决于情况。现在有道理了:)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-09-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-19
    相关资源
    最近更新 更多