Java/Xtend中兼容同API不同包名依赖双版本的方案问询

Great question! The adapter pattern is exactly the elegant, type-safe solution you’re looking for here—and Xtend actually makes this approach even cleaner, not harder. Let’s break down how to implement it, and why Xtend is a plus for this scenario.

The Core Idea: Adapter Pattern for Unified Interfaces #

Instead of maintaining duplicate code or relying on messy reflection, you’ll create a custom interface that defines the common API contract shared by both dependency versions. Then you’ll write thin adapter classes that wrap each version’s concrete implementation and map it to your unified interface. Your business code will only ever interact with this interface, so it never needs to know about the different package names.

Step 1: Define Your Unified Interface #

First, extract all the methods you need from both dependency versions into a single interface. For example, if both com.oldpkg.UserService and com.newpkg.UserService have a getUserById(String) method (and return a user object with id and name fields), your interface might look like this in Xtend:

interface IUserService {
    def UserDTO getUserById(String userId)
}

// Also define a unified DTO if the dependency's user classes are in different packages
class UserDTO {
    val String id
    val String name

    new(String id, String name) {
        this.id = id
        this.name = name
    }
}

Step 2: Write Adapter Classes for Each Dependency Version #

Create an adapter for each package’s implementation that wraps the original instance and translates it to your interface. Xtend’s concise syntax makes this super clean:

// Adapter for the old package version
class OldUserServiceAdapter implements IUserService {
    private val com.oldpkg.UserService delegate

    // Constructor takes the original service instance
    new(com.oldpkg.UserService delegate) {
        this.delegate = delegate
    }

    override getUserById(String userId) {
        // Map the old package's User to our unified UserDTO
        val oldUser = delegate.getUserById(userId)
        new UserDTO(oldUser.id, oldUser.name)
    }
}

// Adapter for the new package version
class NewUserServiceAdapter implements IUserService {
    private val com.newpkg.UserService delegate

    new(com.newpkg.UserService delegate) {
        this.delegate = delegate
    }

    override getUserById(String userId) {
        val newUser = delegate.getUserById(userId)
        new UserDTO(newUser.id, newUser.name)
    }
}

Step 3: Use a Factory to Create the Right Adapter #

To avoid scattering package-specific logic around your code, use a factory class to instantiate the correct adapter based on which dependency is available (via class loading checks, or configuration):

class UserServiceFactory {
    def static IUserService createUserService() {
        try {
            // Try to load the old package's class first
            val oldServiceClass = Class.forName("com.oldpkg.UserService")
            val oldServiceInstance = oldServiceClass.newInstance() as com.oldpkg.UserService
            return new OldUserServiceAdapter(oldServiceInstance)
        } catch(ClassNotFoundException e) {
            // Fall back to the new package if the old one isn't present
            val newServiceInstance = new com.newpkg.UserService()
            return new NewUserServiceAdapter(newServiceInstance)
        }
    }
}

Step 4: Use the Unified Interface Everywhere #

In your business code, you’ll only ever reference IUserService—no more package-specific imports or Object parameters:

class UserBusinessLogic {
    def processUser(String userId) {
        val userService = UserServiceFactory.createUserService()
        val user = userService.getUserById(userId)
        // Do your business logic with the unified UserDTO
        println("Processing user: " + user.name)
    }
}

Why Xtend Makes This Better #

Xtend’s features simplify this pattern even further:

• Concise adapter implementations: You can use Xtend’s lambda syntax for single-method interfaces to avoid writing full adapter classes. For example:

  def static IUserService adaptOldService(com.oldpkg.UserService service) {
      [userId | 
          val oldUser = service.getUserById(userId)
          new UserDTO(oldUser.id, oldUser.name)
      ] as IUserService
  }
  

• Type safety: Unlike reflection, all adapter logic is checked at compile time—no runtime surprises from misspelled method names.
• Seamless integration: Xtend compiles to Java bytecode, so your adapters will work perfectly with both dependency versions, no compatibility issues.

Bonus: Handling Minor API Differences #

If the two dependency versions have small discrepancies (e.g., a method renamed slightly), your adapter can handle the translation internally. For example, if the old version has fetchUser(String) instead of getUserById(String), the adapter can map that:

override getUserById(String userId) {
    val oldUser = delegate.fetchUser(userId) // Map the old method name to our interface
    new UserDTO(oldUser.id, oldUser.name)
}

This keeps your business code untouched even if the dependencies have minor breaking changes.

内容的提问来源于stack exchange，提问作者kutschkem