Greedy Boss – Adapter Pattern

You work for a company which its goal is to held concerts all of the world, your job is to model seats of concerts and everything is clear, You know Object Oriented very well and this task is just a kidding 😉 So you start your modeling. In this domain you have some seats, some of them are first class and the others are business. Audience can sit on a sit if the seat is empty.

So you start your task, Hmmm maybe at first you like to model seats with an interface, it is a good choice, at all preferring interfaces to concrete class is not bad.

public interface Seat {
 void sit(Audience audience);

Boolean isEmpty();

void release();

Audience getAudience();
}

Seat interface is very simple, understandable and you follow “Interface Segregation Principle”  well. Now you implement Business seat and First class seat very easy. Maybe there are some duplicated code that you can solve them with an abstract class, because their duplicated code is static, but it’s not our case.

Your boss wants to held a concert in a green field! At first it’s just strange but you think why your boss wants to do that? Boss found a green field with many stumps! HAHA you are right, your boss wants to sell ticket for sitting on stumps too. He wants you change your model to support stumps as seat too. Stump implementation has been specified before your entrance and you have to use it.

public class Stump {
 private boolean empty;

public void sit() {
 empty = false;
 }

public void release() {
 empty = true;
 }
}

public boolean isEmpty() {
return empty;
 }

Very very simple implementation of stump, but don’t forget you must not change the stump class to implement your Seat interface, it’s obvious. Stump is not a seat at all just you want to use it as a seat in your current model. So what is your solution?

All you need is to extend stump and add new Seat interface to it. For this purpose you can create a new class which implements Seat interface, then your new class has a composition relation with Stump class. then you can write your adapter codes in your new intermediate class.

public class StumpAdapter implements Seat {
 private final Stump stump;
 private Audience audience;

public StumpAdapter(Stump stump) {
 this.stump = stump;
 }

@Override
 public void sit(Audience audience) {
 this.audience = audience;
 this.stump.sit();
 }

@Override
 public Boolean isEmpty() {
 if (this.audience == null) {
 return this.stump.isEmpty();
 }
 return false;

}

@Override
 public void release() {
 this.audience = null;
 this.stump.release();
 }

@Override
 public Audience getAudience() {
 return this.audience;
 }
}

In your new Adapter you keep information and add behaviors that you need to adapt your legacy interface  or class to need interface or class.

Now for testing your code you can write an epic test:

public class ConcertTest {
 @Test
 public void concert_epic() {
 SimpleAudience audience1 = new SimpleAudience();
 Stump stump = new Stump();
 final Seat stumpAsSeat = new StumpAdapter(stump);
 stumpAsSeat.sit(audience1);
 Assert.assertEquals(audience1, stumpAsSeat.getAudience());
 stumpAsSeat.release();
 Assert.assertTrue(stumpAsSeat.isEmpty());

}
}

Congratulation you could adapt your legacy code with your new design, You can use this pattern every time that you are the owner of code, legacy code and the most important when you want to follow “Open Close Principle”.