Java：使用一个类生成另一个类的对象

发布于 2024-08-06 06:04:32 字数 266 浏览 5 评论 0原文

我有两节课。 SpeciesReader 获取文件并解析它们。 Species 存储有关某个物种的某些数据，这些数据已从文件中解析出来。

目前，我有一个方法：SpeciesReader.generateSpecies()，它使用实例化它的文件来创建 Species 对象。这是不好的做法/设计吗？我是否应该找到一种方法将其移至以文件名作为参数的 Species 构造函数？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

仅此而已 2024-08-13 06:04:32

一点也不。这是一种称为工厂的常见模式。

话虽这么说，工厂通常是在类本身（在本例中为 Species）上实现，而不是在单独的类上实现，但我认为这样分离它没有问题。

至于这个责任是否应该由物种承担，这取决于文件的性质。如果一个文件仅包含一个物种，并且加载该文件没有太大的开销，那么将其作为物种的一部分可能是有意义的。

但是，如果文件包含大量物种或者初始化成本很高，那么将该责任转移到另一个类并让它负责创建物种对象是非常有意义的。

回复收藏 0 原文

我一向站在原地 2024-08-13 06:04:32

您可以使用以下几种模式：

选择实现哪种模式取决于用例，但 Cletus 是正确的，工厂似乎是一个不错的选择。

public class SpeciesFactory
{
    private final static SpeciesFactory INSTANCE = new SpeciesFactory();

    private SpeciesFactory() { }

    public static SpeciesFactory getFactory() 
    {
        return INSTANCE;
    }


    public Species getSpecies(String filename)
    {
        Species species = null;
        //do business logic
        return species;
    }

}

您可以通过调用 Species carnivore = SpeciesFactory.getFactory().getSpecies("carnivore.txt"); 来使用它

There are a few patterns you could use:

The choice of which pattern to implement would depend on use case, but Cletus is correct, factory seems like a good choice.

public class SpeciesFactory
{
    private final static SpeciesFactory INSTANCE = new SpeciesFactory();

    private SpeciesFactory() { }

    public static SpeciesFactory getFactory() 
    {
        return INSTANCE;
    }


    public Species getSpecies(String filename)
    {
        Species species = null;
        //do business logic
        return species;
    }

}

You would use it by calling Species carnivore = SpeciesFactory.getFactory().getSpecies("carnivore.txt");

回复收藏 0 原文

前事休说 2024-08-13 06:04:32

您拥有的是工厂方法模式的示例。这种创建模式在某些情况下可以很好地使用。然而，我个人的偏好是尝试将其用法限制为仅作为更易读的 actor 替代品，而不是在其中执行任何过于复杂的操作。这是为了简化依赖于该工厂的任何类的测试。

对于结构复杂的东西，我会使用抽象工厂。这样我就可以测试依赖于所述工厂的组件，而无需创建一堆文件和工厂具有的任何其他依赖项。

上面您询问了 Singleton 与工厂中的静态方法。我对此的看法是：静态方法有利于可读的构造函数，单例方法会激怒任何偏好单元测试。

回复收藏 0 原文

千纸鹤 2024-08-13 06:04:32

将文件的解析与从该文件解析的对象的实现分开是一个好主意。这称为“关注点分离”。 Species 的实现不应该知道或关心它如何在持久性存储中表示（用 OO 设计术语来说，它应该是“持久性不可知的”）或者传递给其构造函数的参数来自何处。它应该只关心创建后如何与系统中的其他对象交互，无论创建是如何发生的。对物种如何在持久存储中表示的关注应该在其他地方实现，在您的例子中是在 SpeciesReader 中。

回复收藏 0 原文