디자인 패턴과 알고리즘

 디자인패턴과 알고리즘을 공부하면, 뭔가 업무에 당장 적용해보고 싶어진다. 이걸 이 패턴에 적용해보면 좋겠하고 생각했지만 막상 적용하려고 하면 어렵다. 곰곰이 생각해보니 Spring web MVC를 사용중이라면, 이미 자연스럽게 MVC 패턴을 사용중일 것이다. 그렇다면, MVC패턴을 파괴하지 않는 선에서 다른 디자인 패턴을 적용해야하는 제약이 생긴다. 

 

 우선, 디자인패턴 책의 예시와 실제 프로젝트가 풀어야하는 문제와 환경 사이에 괴리감이 있기 때문에, 디자인 패턴을 공부해도 실제 프로젝트에 당장 적용할 수 없다. 디자인패턴 책들은 Service -> Dao 계층을 파괴하지 않으면서, Dao를 통해 DB에 저장된 값을 가져오는 예시가 없다. 현재 비즈니스 문제를 해결하기 위한 패턴을 찾았어도 Dao를 통해 정보를 가져와야 한다면, 패턴을 적용할 수 없다. Service -> 디자인패턴 클래스 -> Dao로 계층이 하나 더 추가되기 때문이다. 

 

 디자인 패턴을 적용할 수 있는지 없는지 빠르게 확인하는 방법을 생각해봤다. Spring MVC에서는 View -> Controller -> Model(Service -> Dao)로 계층이 생기며 각각 책임이 분리된다. 단순하게 비즈니스 로직 측면만 바라보자면 보통 Service에 디자인 패턴이 적용될 것이다. 일단 함수의 책임과 동작을 분리하는 것에서 시작한다. 하나의 함수는 어떤 명령을 수행하거나 반환하거나 둘 중하나만 해야한다. 수행은 Insert, update 등과 같은 동작이고, 반환은 복잡한 비즈니스 로직을 처리하는 동작을 수행 후 값을 반환하는 것이다. 디자인 패턴은 이 반환 메서드에 비즈니스 로직에서 해결해야하는 문제와 디자인 패턴이 해결하고자 하는 문제가 같을 때 적용할 수 있을 것이다.

 

  프로젝트를 하면서, 실력이 눈에 띄게 좋아지는 것을 보고 싶으면, 사용하는 IDE, 기술들을 공부는 것이 좋다. IDE를 사용하여 단축키를 외우고 익숙하게 사용하게 되면 개발 속도가 빨라진다. 기술, 예를 들어, Kotlin과 같은 언어를 공부하면 associateWith(), associateBy()...등등 편의 메소드들을 활용할 수 있고, Comparator, 동등성, 동일성 등을 알게 된다면 더욱 간결한 코드를 작성할 수 있을 것이다. (IntelliJ, Kotlin, Spring 등등...)

 

 디자인패턴이나 알고리즘은 일반적으로 적용하기에 범위가 매우 좁다 생각하지만, 비즈니스 로직이 아니라 DB를 통해 정보를 가져오지 않는 오픈소스 라이브러리, 인가 인증 등에서는 활용 범위가 크다 생각한다. 그래서 공부하지 않을 순 없다.  시니어나 전문가는 해결이 필요한 문제 상황에서 적절한 해답을 만들어내는 사람들이니까..!