When evolving APIs, maintain backward compatibility to avoid breaking client code. Consider these guidelines: 1. **Add overloaded methods instead of modifying signatures**: When adding parameters, create a new method rather than changing an existing one.
When evolving APIs, maintain backward compatibility to avoid breaking client code. Consider these guidelines:
// AVOID: Breaking change by modifying existing method
- public DockerConfiguration withHost(String address, boolean secure, String certificatePath) {
+ public DockerConfiguration withHost(String address, boolean secure, String certificatePath, Integer socketTimeout) {
// PREFER: Add an overloaded method
public DockerConfiguration withHost(String address, boolean secure, String certificatePath) {
return withHost(address, secure, certificatePath, null);
}
public DockerConfiguration withHost(String address, boolean secure, String certificatePath, Integer socketTimeout) {
// Implementation
}
// AVOID: Breaking change by narrowing type
- protected Function<String, String> getDefaultValueResolver(Environment environment) {
+ protected UnaryOperator<String> getDefaultValueResolver(Environment environment) {
// PREFER: Keep compatible types or provide adaptation layer
protected Function<String, String> getDefaultValueResolver(Environment environment) {
// Implementation
}
For functional interfaces, avoid changing the abstract method signature: This preserves lambda compatibility.
// AVOID: Restrictive single value
private String audience;
// PREFER: More flexible collection that handles current and future cases
private List<String> audiences;
These practices help maintain a stable API contract while allowing your library to evolve.
Enter the URL of a public GitHub repository