Question

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

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

Answer 1

完全没有。这是一种称为工厂的常见模式。

话虽这么说，工厂通常是在类本身（在这种情况下是物种）上实现的，而不是单独的类，但我认为将它分开是没有问题的。

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

但是如果文件包含大量物种或者初始化很昂贵，那么将这个职责转移到另一个类并让它负责创建Species对象是完全合理的。

Answer 2

您可以使用一些模式：

选择实现哪种模式取决于用例，但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”）;

来使用它

Answer 3

你所拥有的是Factory Method Pattern的一个例子。在某些情况下，此creational pattern可以很好地使用。然而，我个人的偏好是尝试将其使用限制在ctor更易读的替代品中，而不是在其中做任何过于复杂的事情。这是为了简化依赖于此工厂的任何类的测试。

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

上面你要问的是在工厂中使用Singleton与静态方法。我对此的看法是：静态方法对于可读的ctors是有益的，单身对任何偏好unit testing的人都有好处。

Answer 4

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

Answer 5

将对象与其持久化方式分开通常更好。想象一下，如果有很多方法可以加载 Species - 来自二进制文件，xml文件，数据库记录，网络套接字等等 - 穷物种不想知道程序的每个部分。< / p>

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

5 个答案: