最近，我真正专注于编写简洁的代码和实现设计，并且偶然发现了一种情况，我有多种选择，但无法确定哪一种是合适的。我正在开发一个需要在对象集合上保持持久性的软件。我决定实施DAO模式。事实是持久性可能都是Json或Xml，所以我这样实现了：
我创建了一个通用DAO：
public interface GenericDao<T> {
public boolean add(T type);
public boolean change(T type);
public void delete(T type);
}
然后，我创建了一个CarDAO：
public interface CarDao extends GenericDao<Car> {
public Car getByIdentificationNumber(int id);
public void process();
}
对于JSON持久性：
JsonGenericDao：
public class JsonGenericDao<T> implements GenericDao<T> {
public boolean add(T type) {
// implement ADD for json
}
public boolean change(T type) {
// implement Change for json
}
public void delete(T type) {
// implement Delete for json
}
}
JsonCarDao：
public class JsonCarDao extends JsonGenericDao<Task> implements CarDao {
public Car getByIdentificationNumber(int id) {
// Implement logic
}
public void process() {
// Logic
}
}
JsonCarDao扩展了JsonGenericDao以包括添加，更改，删除，并且还提供了其他方法。XmlGenericDao和XmlCarDao的实现方式相同。因此，最终我可能要使用
XmlCarDao或JsonCarDao，这取决于我要使用的持久性。实现持久性时，我将
JAXB用于XML，将Gson用于JSON。我创建了一个
EntityCollection<T>类，将对象存储在内部，然后根据使用的持久性将该集合转换为XML或JSON，然后从文件中检索信息到该集合，更改需要更改的内容，然后重新编写文件。有两种实现方法：
选项1：
我可以在
Gson内使用JsonGenericDao来实现持久性，并对JAXB内的XmlGenericDao做相同的事情。选项2：
我可以创建一个接口
Persister<T>并编写两个实现该接口的类，因此JsonPersister<T>和XmlPersister<T>使用诸如update(T type)和acquireAllFromFile()之类的方法，其中之一将用新的方法重写整个文件。数据，另一个将从文件中检索信息。 （可以在选项1中完成相同的操作，但无需添加其他类）然后在
JsonGenericDao<T>中，我可以使用：JsonPersister<EntityCollection<T>>在
XmlGenericDao<T>中，我可以使用：XmlPersister<EntityCollection<T>>因此打包所有东西。
尽管这里的问题正在考虑这个问题，这意味着我可以摆脱
JsonGenericDao和XmlGenericDao并实现单个PersistenceGenericDao，这将在其CONSTRUCTOR内部使用Persister接口来指定或使用JsonPersister。它基本上是XmlPersister和DAO的组合。现在，这似乎是我可以做的事情..但对我来说，它也弄乱了我最初的DAO设计。这是合适的做法还是不好的做法？ 最佳答案
我认为您的选项2实际上看起来像GoF Bridge Pattern。 XmlPersister / JsonPersister是ConcreteImplementor。 PersistenceGenericDao是Abstraction，JsonCarDao是RefinedAbstraction。
所以这个想法实际上是有道理的。请参见What problems can the Bridge design pattern solve?以检查您是否确实需要该模式。
如果仅计划使用XML或JSON持久性，我个人将使用选项2。如果将JsonCarDao与XmlCarDao进行比较，则它们之间的唯一区别可能是从某些资源（JSON）保存/加载数据的机制。与XML）。其余逻辑可能大致相同。从这个角度来看，将“保存/加载”提取到特定的实现程序中并为其余DAO逻辑使用一个通用类是合理的。
但是，如果考虑关系型或NoSQL数据库的持久性，则可能不太适合。因为DAO逻辑可能会有所不同。与JSON DAO（从JSON文件加载数据并在对象集合中搜索具有给定ID的对象）相比，类似findById的方法在关系DAO（数据库中的查询）中将大为不同。在这种情况下，RelationalPersistence可能不是很有效。
关于java - Java CRUD DAO持久性设计，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48850314/