Java 抽象工厂模式接口实现或类扩展

我目前正在为数据库连接实现一个抽象工厂模式，我需要分离业务逻辑，并为每个需要连接到我的应用程序的新数据库类型编写不需要重写的代码， 所以在这一点上，我有这些类

Interface Connection{}
MySql implements Connection{}
PostgreSql implements Connection{}

所以这里的问题是，实现接口连接的每个类都必须重写接口中的方法，我需要一个类，其中有诸如setStatement、executeQuery等通用方法，但是som方法需要被重写，就像connect方法一样，根据数据库类型的不同而有所不同

我的第一个想法是在接口连接和子类之间有一个额外的类， 如果不重写，则保留并使用这些方法，但这种解决方案感觉不是正确的方法（如果我错了，请纠正我）

---

谢谢

没问题。但我会这样做：

interface Connection{}
abstract class AbstractConnection implements Connection {}
final class MySql extends AbstractConnection{}
final class PostgreSql extends AbstractConnection{}

在Java8中，您还可以在接口中使用默认方法，而不使用抽象类

---

一种完全替代的方法是提供方法的类

DefaultConnectionOperations

。然后您可以拥有这个类的一个对象，它被注入到每个连接实现中。但是，如果你的案例中需要依赖注入，这是有争议的。

我不明白为什么不考虑过度继承。这是一个额外的问题——为什么

这样做

每种新的数据库类型

当连接类型更改时，可以更改连接的行为。也会出现已经相应改变的情况。状态模式还允许您保留前一个状态的属性，即使之后状态发生更改

实现的伪代码：

class Connection{
private State _state;
}

abstract  class State{
protected Connection connection;
}

class MySqlState extends State{}
class PostgreSqlState extends State {}

---

我会用另一个名字。连接已经是一个JDBC实体。我的类的名称实际上是ConnectionBase，但thx无论如何我的问题是我们仍然在使用java 1.6。如果我连接到一个抽象类，并且在该类中有通用方法和变量，并且有子类来覆盖一些在impl'方面不同的方法，会怎么样？这会对工厂模式产生影响吗？@MRK187您可以这样做，但是工厂方法的返回类型不应该是抽象类，而是抽象类实现的接口。您应该始终使用接口，因为即使是包含默认实现的抽象类也可能是可交换的。尽管这感觉需要做大量工作，但我可以只使用抽象顶级类，而让其他类继承，这有什么区别？似乎很难达到同样的效果。更好的可测试性。看看这个数据库中的#5优势（单元测试），以及它与OO设计中的“重组合轻继承”规则的关系。那么在你的伪代码中，你指的是创建一个自己的类还是导入一些现有的类状态？如果你能重用一些代码会更好。但是在新的State类中，您可以定义逻辑来封装与连接类的特定状态（MySql、PostgreSql、Oracle）相关的行为。我真的不理解区别，除了子类能够改变状态，这在我的实现中是不需要的，因为数据库将来自不同的客户等，所以最简单的方法是在上面有一个类，然后让其他类扩展该类并重写，为什么这不是首选方法？

class Connection{
private State _state;
}

abstract  class State{
protected Connection connection;
}

class MySqlState extends State{}
class PostgreSqlState extends State {}