Domanda

A Java project I've been working on integrates with several RDBMSs. The most obvious way for us to reduce the code duplication between the way we handle them is to make a type hierarchy like:

               ThirdPartySoftware (superclass)
                      /|\
                     / | \
                 TPS1  2  3

However, this approach has ended up with implementations for TPS1, TPS2, and TPS3 being very similar (but not quite!). It's difficult to pull all the functionality into the superclass without the superclass essentially being aware of every place that something could be different, defeating the encapsulation subclassing is meant to buy us.

One method we've considered is representing the DBs by features that they share, such as "supports feature X" and "can't do feature Y", however it's not altogether clear that the code would end up being more maintainable that way because:

  1. Many of the quirks only apply to one DB.
  2. We can't think of enough shared/comparable (basically, abstract-able) features to make this worthwhile.

Does anyone have other suggestions of ways we could reduce the code duplication between the subclasses, perhaps using a design pattern?

È stato utile?

Soluzione

http://en.wikipedia.org/wiki/Bridge_pattern

looks just for your case but anyway it will be your job to find out what is the API.

Perhaps, org.hibernate.dialect.Dialect will give you some new ideas.

Altri suggerimenti

I am not a java guy, but in addition to the superclass / abstract class you could use interfaces and dependency injection along with the repository pattern. These patterns are not exclusive, I frequently have interface implementations that are subclasses of a master class such as

SqlDataAccess : BaseDataAccess, IDataAccess and TPSDataAccess : SqlDataAccess, ITPSDataAccess

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top