feat: add a separation of concerns.md

_posts/2023-12-17-separation-of-concerns.md

@@ -0,0 +1,38 @@
+---
+title: 관심사의 분리
+categories: [Computer science, Object Oriented Programming]
+tags: [Object Oriented Programming, object, OOP, Separation of Concerns, SoC, 객체 지향 프로그래밍, 객체, 관심사의 분리]
+---
+
+이번 포스팅에서는 객체 지향 설계에 있어 중요한 개념인 "관심사의 분리"에 대한 정의, 그리고 이 개념이 필요한 상황을 구체적인 코드와 함께 알아보겠습니다.
+
+## 관심사의 분리란?
+우선, 관심사의 분리를 위키피디아에 검색해보면 다음과 같습니다.
+
+>컴퓨터 과학에서 관심사 분리(Separation of Concerns, SoC)는 컴퓨터 프로그램을 구별된 부분으로 분리시키는 디자인 원칙으로, 각 부문은 개개의 관심사를 해결한다. 관심사 분리를 이용하면 프로그램의 설계, 디플로이, 이용의 일부 관점에 더 높은 정도의 자유가 생긴다.
+{:.prompt-info}
+
+관심사의 분리는 디자인 원칙 중 하나이고 이를 이용해 프로그램에 더 높은 자유도를 제공할 수 있다 정도로 나와있는데 사실 말만 들어서는 "관심사"라는 키워드 자체가 Computer Science에서 무엇을 의미하는지가 와닿지가 않습니다.   
+그래서 공연이란 키워드로 좋은 예시를 하나 들어보겠습니다. 저희가 만들 시스템 혹은 애플리케이션을 하나의 로미오와 줄리엣 공연이라고 생각해봅시다. 이 로미오와 줄리엣 공연에는 로미오라는 배역, 줄리엣이라는 배역 등이 있을 겁니다. 그리고 그 배역을 실제로 무대에서 연기해줄 배우들이 따로 있습니다.   
+앞선 포스팅에서 객체 지향 설계에 대해 설명하면서 역할과 구현을 나누는 것이 굉장히 중요하다라고 말씀드렸는데, 바로 공연의 배역이 객체 지향 설계에서의 역할이고 실제 배역을 소화해 내는 배우들이 구현이라고 생각하면 좋습니다.   
+여기서 배우의 역할과 책임은 무엇일까요? 네 맞습니다. 배역을 잘 이해하고 잘 연기하는 것입니다.   
+그렇다면, 다른 상황을 가정해보겠습니다. 로미오라는 배역을 연기하는 배우가 마치 영화 감독자, 캐스팅 담당자처럼 상대 배역인 줄리엣 배역을 맡아줄 여배우를 찾으러 다니고 섭외하러 다니는 것은 배우의 역할과 책임에 온전히 집중하는 것이라고 말할 수 있을까요? 배우는 연기를 하는 사람이고, 배우라는 역할에 집중하는 건 연기에 집중하는 것을 의미하지 섭외와 같은 다른 활동을 병행하는 것은 적어도 본인 책임에만 전념한다라고 말할 수는 없을 것입니다.   
+이 상황에서 필요한 것이 바로 **관심사의 분리**입니다. 각자 해야되는 책임에 맞게 관심사를 나누어서 배역에 맞는 배우를 섭외하러 다니는 건 캐스팅 담당자의 역할이므로 별도로 캐스팅 담당자라는 역할을 만들어줘야 한다는 것입니다.   
+
+## 관심사의 분리가 필요한 상황
+코드를 보면 이해가 더 쉬우므로, 관심사의 분리가 필요한 상황을 이전 포스팅에서 사용했던 Java 코드로 나타내보겠습니다.
+
+```java
+public class UserService {
+    private UserRepository userRepository = new MemoryUserRepository();
+}
+```   
+
+위 코드는 User와 관련된 비즈니스 로직을 처리하는 UserService라는 코드이고 이 안에서는 Repository 레이어를 위해 MemoryUserRepository라는 구현체를 직접 생성해서 넣어주고 있습니다. 이는 이전 포스팅에서 배웠듯이 DIP에 대해 위반하고 있는 코드입니다. DIP에 따르면 프로그래머는 추상화(역할)에 의존해야지 구현체에 의존하면 안된다고 배웠습니다. 하지만 위 코드는 UserRepository라는 추상화와 MemoryUserRepository라는 구현체 모두에 의존하고 있는 코드입니다. 이때 필요한 것이 바로 **관심사의 분리**입니다.   
+이를 DIP가 지켜질 수 있도록 관심사의 분리를 통해 수정해줄 수 있는데, 간단합니다.   
+UserService에서 필요한 userRepository를 필드에서 주입받도록 하지 않고 그냥 필드로만 놔두고, 이를 외부에서 주입받을 수 있도록 userRepository 필드에 대한 생성자를 만들어줍니다.   
+그 후, 외부에서 이 필드에 구현체를 넣어줄 수 있도록 클래스와 메서드를 작성해주기만 하면 됩니다. 이처럼 외부에서 구현체를 넣어주는 것을 **의존성 주입(Dependency Injection, DI)**라고 합니다.
+
+## 마무리
+지금까지 관심사의 분리에 대한 정의와 관심사의 분리가 필요한 상황에 대해 코드와 함께 알아봤습니다. 관심사의 분리도 사실 결국은 단일 책임 원칙을 지키는 것과 같이 하나의 역할에 과도한 책임을 주는 것을 막기 위해 관심사를 분리하여 잘게 쪼개야 함을 의미한다고 이해하면 쉽습니다. 그 예시로 앞선 포스팅에서 작성했던 코드를 가져와 의존성 주입 개념과 함께 설명드렸습니다.   
+이렇게 작성하다 보니 객체 지향 설계는 변경을 용이하게하고 변화에 쉽게 대응할 수 있도록 만들기 위함이라는 것과 그리고 그 목표를 이루기 위해 하나의 책임을 가진 역할로 잘게 쪼개고 이 역할들 간의 협력으로 시스템을 구축해나가고 있다는 것을 다시 한번 느낄 수 있었습니다.