[Spring] 관습적인 추상화

문제 인식

대부분 프로젝트를 할 때 Service를 인터페이스로 만들고 ServiceImpl을 구현체 클래스로 만들게 됩니다.
이렇게 인터페이스와 클래스로 분리하는 이유는 구현체를 독립적으로 확장할 수 있으며, 구현체 클래스를
변경하거나 확장해도 클라이언트의 코드에 영향을 주지 않기 때문입니다.

또한 위와 같은 추상화 방식을 사용하여 구현하므로써 객체지향의 다섯가지 원칙 중 하나인 OCP원칙을
잘 지키는 설계 방식이라고 할 수 있습니다. 

[Spring] 객체 지향 설계의 다섯 가지 기본 원칙 - SOLID

하지만 실제로는 인터페이스와 구현체 사이의 관계가 1대 1의 관계로 구성되어 있기 때문에 확장성과
클라이언트 코드의 영향성에 대한 이점을 전혀 가져가지 못하고 있습니다.

결과적으로 코드 구조가 복잡해지고 코드에 대한 가독성이 떨어지게 됩니다. 이러한 문제를 많은 사람들은
관습적인 추상화라고 합니다.

이미지 출처: https://see-one.tistory.com/1

 

결과

객체는 변화하며 개발자는 끊임없이 변화에 대비해야한다. 미래를 위한 설계를 통해 변화에 효과적으로 대처할 수 있다.

위의 말 처럼 당장은 1대1 관계를 맺고 있을지도 모르지만 서비스가 커지고 변화함에 따라
구현체 클래스는 확장될 가능성이 있습니다. 그렇기 때문에 인터페이스와 구현체를 분리한 설계를 통해
미래의 변화에 유연하게 대처해야 합니다.

또한 이러한 개념도 모르고 무분별하게 추상화를 사용하기 보다, 미래를 생각하고 변화에 대비하는 마음을 가지고
추상화를 사용하여 설계한다면 나중에 훌륭한 개발자로 성장할 수 있다고 생각했습니다.

 

추가

미래에 확장할 가능성과 변화에 대비하여 1대 1로 구성된다고 해도 추상화를 사용하고,
추상화를 적용했을 때는 읽기 좋고 객체지향적 특징을 잘 살릴 수 있는 방법을 생각해봤을 때
서비스 고유의 특징에 따라 구현체의 이름을 설정하는 것이 좋다는 의견도 있습니다.

 

 

[참고]

1. 관습적인 추상화 - See One