在我通常将我的整个域声明为s，可能带有某种实现方式。这部分是因为我太老了，我记得当一些持久性层需要实现类来子类化一个特定的类时，但也让我可以很容易地：JavainterfaceFactory
我遵循这种做法，即使我并没有真正设想我实际上想要做上述任何一件事;我仍然认为这是很好的做法，以防万一。我认为这是一种相当普遍的方法。
如果我声明所有域对象，这在Scala-land中会很不寻常吗？上述观点也适用于Scala吗？abstract
Scala具有特征，即裂纹上的接口。真的，它们应该是接口，诚然，当涉及到构造函数时存在局限性，但考虑到如果你有两个接口都有构造函数的要求，这实际上并不是什么大问题，你会遇到同样的问题。
然后是部分方法，在很多方面，许多基于依赖关系管理的面向对象设计原则几乎可以被视为获得更易于组合的工作单元的方法，你真的不得不怀疑。您不仅可以处理方法输入和输出，或者使用策略对象/方法的预定义点，而是具有更大的灵活性。
再加上伴随的物体，突然之间，工厂和更多的工厂变得更加微不足道。
鉴于这种情况，你真的可以摆脱到处使用接口的麻烦，并且使用更强大的泛型系统，使用接口完成的一些事情会被吸到那里。
一般来说，在Scala代码中，它往往是相当分解的，而接口似乎不是其中的主要工具。
这是一个非常发人深省的问题。
这似乎不是一种常见的模式（至少在我见过的Scala中），但如果这是你真正想做的，我就不能从头顶上想到一个很好的论据来反对它。
另一方面，我不认为我会那样做（当我有实际需求时，我会重构，而不是为可能永远不会到来的假设未来建立这样的“灵活性”）。但是我能想到的反对它的最佳论据是避免不必要的间接寻址的类比（当你所需要的只是一个整数时，不要使用指向指向整数的指针的指针），这并不是很有吸引力。
