Question: I have to implement a Client/Server architecture in Java, where the Server may change in the future (well, it definitely will at some point).

What would be the best way to take that possible change into account? Here's what I thought of:

1.) Create an interface for the Server:

```
public interface AlarmService {
  ...
}

```

2.) Create a concrete implementation:

```
public AlarmServiceImpl implements AlarmService {
  ...
}

```

3.) Write a static factory to get some sort of implementation

```
public AlarmServiceFactory {
  private AlarmService AlarmServiceFactory() {
    return new AlarmServiceImpl();
  }
}

```

Is this a good idea? Or is this too much? Or maybe I shouldn't take that change into account?

Answer: 
There is a mantra that goes something along the lines of "always program to an interface, not an implementation". While true in many cases, a lot of time it is overkill. In your case though, since you KNOW the implementation will change, and you won't have as much control over the clients as you do the server, you should definitely program to an interface.

The factory will only really be useful in two cases. The first being that you have several Implementations available, and you need to decide which one to produce at run-time. The other is if you are creating new `AlarmServiceImpl()` all over the place, and the implementation changes. Otherwise, I see the use of a factory as overkill. 

So.. definitely build an interface for the client/server to communicate through. Only use a factory if swapping or choosing implementations isn't one or two lines of code, and is scattered in various places.
Consider [Business Delegate](http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html) pattern. It's more powerful than just interface/implementation suggested already.