오늘은 저번시간에 이어 개방 폐쇄 원칙(Open-clased principle) 대해서 알아보도록 하자. 예제를 고민하느라 책도 많이 참고 했고 인터넷 정보도 많이 활용했다. 계속 이 원칙들을 살펴봐야 되는데 중간중간에 다른 포스팅을 하느라 저번 포스팅이 어디있는지도 모르겠다. 오늘도 역시 단일책임원칙은 못한다.
개방 폐쇄 원칙 (OCP)
조금 모순이 있는 단어같다. 개방과 폐쇄가 공존한다. 하지만 여기에는 깊은 뜻이다. 일단 개방 폐쇄 원칙이 무엇인지 살펴보자. 개방 폐쇄 원칙이란 (OCP) 확장에는 열려 있어야 하고, 변경에는 닫혀있어야 한다. 라고 정의 되어있다. 흠.. 무슨 이런 어이 없는 말을 할까하는데 좀 더 풀어서 이야기 하면 다음과 같다.
기능을 변경 또는 확장할 수 있으면서 그 기능을 사용하는 코드는 수정하지 않아야 한다. 라고 하면 좀 더 와닿을까? 근데 그게 가능할까나 어떻게 변경하거나 확장하면서 그를 사용하는 코드는 수정하지 않아야 한다니 말이다. 먼저 글(의존 역전의 원칙) 을 읽었다면 가능해 보인다. 왜나면 의존역전의 원칙을 잘 지키면 개방 폐쇄 원칙도 알아서 잘 지켜지니 말이다.
일단 우리는 어떤 파일을 읽어와 엑셀로 다운로드 한다는 기능이 있다고 가정하자. 그걸 코드로 작성해보면 다음과 같다.
public class ExcelController {
private final FileByteReader fileByteReader = new FileByteReader();
public void download() {
byte[] read = fileByteReader.read();
//blabla
}
}
public class FileByteReader {
public byte[] read() {
//파일을 읽는다.
return new byte[0];
}
}
아주 간단한 코드를 작성했다.
ExcelController는 다운로드 하는 부분의 로직이 들어가면 되고
FileByteReader 클래스는 파일을 읽어와 byte 배열로 리턴해주는 코드가 들어가면 되겠다.
ExcelController 클래스는
FileByteReader 클래스를 사용하고 있다. 그러다 어느날 Database에서 값을 꺼내 다운로드 하라는 요청이 들어왔다. 그럼 우리는 다음과 같이 변경해야 한다.
public class ExcelController {
private final DataBaseByteReader dataBaseByteReader = new DataBaseByteReader();
public void download() {
byte[] read = dataBaseByteReader.read();
//blabla
}
}
public class DataBaseByteReader {
public byte[] read() {
//데이터 베이스에서 값을 가져온다.
return new byte[0];
}
}
우리는
DataBaseByteReader 클래스를 생성하고 다시
ExcelController에서 사용되었던
FileByteReader를
DataBaseByteReader 클래스로 변경해야 한다. 요구사항이 변경될 때 마다 계속
ExcelController 클래스를 변경해야 한다. 이것은 개방 폐쇄 원칙을 지키지 않아 일어난 일이다. 눈치 빠른 사람들은 눈치 챗겟지만 인터페이스를 이용하면 좀 더 확장성 있게 되지 않을까 생각 한다. 그럼 인터페이스를 만들어보자.
public interface ByteReader {
byte[] read();
}
public class DataBaseByteReader implements ByteReader {
@Override
public byte[] read() {
//데이터 베이스에서 값을 가져온다
return new byte[0];
}
}
public class FileByteReader implements ByteReader {
@Override
public byte[] read() {
//파일을 읽는다.
return new byte[0];
}
}
ByteReader 라는 인터페이스에 read() 라는 메서드를 만들고 구현은 해당 클래스의 맞게 개발하면 된다. 그럼 한번 사용해보자.
public class ExcelController {
private final ByteReader byteReader = new DataBaseByteReader();
public void download() {
byte[] read = byteReader.read();
//blabla
}
}
인터페이스를 이용하여
DataBaseByteReader 클래스를 생성하였다. 하지만 아직까지
FileByteReader 클래스로 변경해야 된다면
ExcelController의 클래스를 변경해야 한다. 아직까지 완벽한 개방폐쇄가 되지 않았다. 엇 이건 저번에 봤던 의존역전원칙과 비슷한 구석이 많다고 생각 들 수 있다. 맞다. 저번에도 말했지만 의존역전원칙을 잘 지키면 개방폐쇄원칙도 자연스레 지키게 된다.
다시 코드를 변경해 보자.
public class ExcelController {
private final ByteReader byteReader;
public ExcelController(ByteReader byteReader) {
this.byteReader = byteReader;
}
public void download() {
byte[] read = byteReader.read();
//blabla
}
}
ByteReader 인터페이스는 사용하는 클라이언트에서 결정하면 된다. 만약 또 다시 요구사항이 추가 되었다고 생각해보자. 이번에는 DataBase에서 값을 가져오는 것이 아니고 타 API를 이용해서 가져와야 한다고 가정해보자.
public class RequestByteReader implements ByteReader {
@Override
public byte[] read() {
//api 호출
return new byte[0];
}
}
API를 통해 값을 가져와 Byte 배열로 가져오는
RequestByteReader 클래스를 만들었다. 그리고
ExcelController를 변경하려고 보니까 그럴 필요가 없어졌다. 왜냐하면
ExcelController 클래스는 직접적으로 어떤 클래스를 사용한게 아니라 의존성 주입을 받고 있기에
ExcelController는 변경이 일어나지 않는다. 이로써 우리는 수정과 확장은 하였지만 코드는 변경하지 않은 개방폐쇄 원칙을 따르게 된 것이다.
개방폐쇄원칙은 꼭 인터페이스만 사용하라는 법은 없다. 상속을 통해서도 개방폐쇄원칙을 지킬 수 있다.
class HttpServlet {
protected void doGet(Request request) {
response.send(400);
}
protected void doPost(Request request) {
response.send(400);
}
// etc..
public void service(Request request) {
if(method.equals("get")) {
doGet(request);
} else {
doPost(request);
}
}
}
어떤 request는 받는 클래스가 있다고 생각해보자.
service()라는 메서드는 요청을 받아서 각각의 상태에 맞게 doGet과 doPost로 전달하는 역할을 한다고 치자. 기본적으로 각각의 상태코드는 400을 리턴한다. 하지만 만약 계정 정보를 조회하는 요구사항이 들어왔다고 가정해보자. 그리고 계정정보의 조회의 상태코드는 get일 경우 에만 200의 상태코드를 리턴해야 한다고 하면 다음과 같이 할 수 있다.
class AccountServlet extends HttpServlet {
@Override
protected void doGet(Request request) {
response.send(200);
}
}
이렇게 HttpServlet 클래스는 변경하지 않고 확장해 나갔던 이유는 바로 개방폐쇄 원칙을 잘 지켜서 할 수 있는 일이 되었다. 가만 보면 위의 코드는 어느 디자인 패턴과 비슷해보인다. 맞다. 디자인 패턴 중
템플릿 메서드 패턴을 사용한 것이다. 템플릿 메서드 패턴은 상위 클래스에서 실행할 기본 코드를 만들고 하위 클래스에서 필요에 따라 확장해가는 패턴으로 아주 유용하게 쓰인다. 나중에 기회가 된다면 패턴들도 한번씩 살펴보기로 하자.
실제 위의 코드는 java servlet의
HttpServlet 클래스를 간단하게 구현해 본 것이다.
HttpServlet 클래스는 템플릿 메서드 패턴으로 구현되어 있다.
이렇게 오늘은 객체지향의 5대 원칙 중 개방폐쇄의 원칙을 살펴봤다. 내용자체는 그리 어려운 말은 아니지만 실제로 구현하려면 많이 생각하고 구현해야 될 듯 싶다. 언제쯤 단일책임원칙의 예제가 생각날까.. 리스코프 치환원칙은 아주 유명한 예제가 있어서 그걸 기반으로 설명하면 될 듯 싶은데.. 단일 책임 원칙은.. 왜이렇게 생각이 나지 않을까
일단 아마도 다음시간에는 리스코프 치환원칙을 살펴볼 듯 싶다. 그럼 오늘은 이만.