게시판에 대한 리팩토링
•
데코레이터 패턴 + 스트레티지 패턴 적용
게시판의 기본 기능
read, write, update, delete에 대한 기본적인 로직들은 인터페이스를 통해 작성해놓음
이런 게시판들은 여러 종류의 게시판으롭 변형될 수 있는데, 이 과정에서 새로운 인터페이스들이 추가될 수 있다. 하지만 기본적인 기능의 게시판 또한 사용할 수 도 있기 때문에 데코레이터를 통해 꾸며주는 걸로 결정
뿐만 아니라, 기존에 있던 게시판이 다른 형태를 요구하는 게시판으로 바뀔 수도 있기 때문에, Concrete한 클래스들을 여러개 만들기보다(변경에 취약함 + 중복되는 코드 다수 발생)
기본적인 기능이 있는 기본 게시판을 데코레이터로 먹어서 구체적인 게시판으로 만드는게(기존 기본 기능은 변경에 덜 취약함, 새로운 데코레이터를 만들어서 먹으면 됨, 변경에 덜 취약함)
프로젝트 전체적으로 봤을 때, 구체적인 게시판의 특정 함수에 대한 의존도를 낮출 수 있다.
(기본 게시판에 대한 메소드를 사용하는 부분은 그냥 데코레이터를 교체하더라도 바뀌지 않고, 교체하는 데코레이터가 완전히 다른 인터페이스를 제공할 때만 해당 데코레이터를 사용하는 부분을 고치면 된다.
근데 이런 건 데코레이터 자체의 인터페이스를 그 때 그 때 마다 확장하면 되기 때문에 큰 문제가 없음)
이 때 각 데코레이터에서 통일된 인터페이스가 존재하게 되는데, 각 데코레이터 별로 다른 형태로 기능을 제공해야할 수도 있다. 그러기 위해서 스트래티지 패턴을 사용해서 데코레이터에서 추가적으로 제공하는 기능에 대해 쉽게 쉽게 교체할 수 있도록 했다.
즉, 공지 게시판을 민원 게시판으로 아예 통으로 갈아끼울 수도 있지만, 기존에 공지 게시판에 특정 메소드를 민원 게시판에 있는 기능으로 맞추고 싶다면, 그저 그 기능에 해당하는 스트래티지만 갈아끼우면 모든 데코레이터를 갈아끼우는 변경을 최소화할 수 있음.
뿐만 아니라, 이렇게 함으로써 게시판에 다양한 기능들을 쉽게 넣고, 뺄 수 있을 뿐만 아니라 데코레이터의 숫자를 크게 늘리지 않을 수 있다. 만약 원래라면 민원 데코레이터 자체를 수정하거나(변경에 취약함) 아니면 아예 새로운 데코레이터를 만들어서 아예 다 갈아끼우던가 해야하는데, 이렇게 하면 특정 데코레이터의 기능(스트래티지) 하나를 추가하고 갈아끼우기만 하면 됨.
