디자인 패턴
은 실제 개발 현장에서 비즈니스 요구 사항을 프로그래밍으로 처리하면서 만들어진 다양한 해결책 중에서 많은 사람들이
인정한 가장 효율적인 예시를 정리한 패턴의 집합이다.
서로다른 두 인터페이스 가이에 통신이 가능하게 하는 것이 가능하다면 어떨까?
이미 나 또한 여러 프로젝트를 하면서 경험한 내용 패턴인데
주로 DBMS를 연결하는 JDBC
가 어댑터 패턴을 이용해 다양한 DB 시스템을 단일한 인터페이스로 조작할 수 있게 해주기 때문이다.
이미 앞선 SOLID
포스팅에서 JDBC
와 JRE
에 대한 이야기를 했으며 이 개념은 어댑터 패턴까지도 사용된다.
즉, 어댑터 패턴
은 OCP
를 활용한 설계패턴 이라고 할 수 있다.
public class ServiceA {
void runServiceA() {
System.out.println("ServiceA");
}
}
public class ServiceB {
void runServiceB() {
System.out.println("ServiceB");
}
}
public class ClientWithNoAdapter {
public static void main(String[] args) {
ServiceA sa1 = new ServiceA();
ServiceB sb1 = new ServiceB();
sa1.runServiceA();
sb1.runServiceB();
}
}
작성해야할 클래스가 많아져서 복잡하게만 보이겠지만
이는 어댑터 클래스 를 기준으로 확장성
을 보이기 위한 패턴임을 알아야한다.
당연하게도 OCP 원칙
을 따른 결과이다.
public class ServiceA {
void runServiceA() {
System.out.println("ServiceA");
}
}
public class ServiceB {
void runServiceB() {
System.out.println("ServiceB");
}
}
public class AdapterServicA {
ServiceA sa1 = new ServiceA();
void runService() {
sa1.runServiceA();
}
}
public class AdapterServicB {
ServiceB sb1 = new ServiceB();
void runService() {
sb1.runServiceB();
}
}
public class ClientWithAdapter {
public static void main(String[] args) {
AdapterServicA asa1 = new AdapterServicA();
AdapterServicB asb1 = new AdapterServicB();
asa1.runService();
asb1.runService();
}
}
어댑터 패턴은 객체를 속성으로 만들어서 참조하는 디자인 패턴으로
호출 당하는 쪽의 매서드를 호출하는 쪽의 코드에 대응하도록 중간에 변환기(어댑터)를 통해 호출하는 패턴