11주차 정리(3/14~18)

일주일은 정말 빨리 지나간다.

특히 금요일 부터 일요일은 그냥 없어진다.

너무 슬프다. 요즘은 요일 감각도 없어지고 있다. 이러다가 날짜 개념이 아예 사라지게 생겼다. 큰일이다.

이번 주차는 객체 지향 개념과 Spring을 시작(환경 세팅 및 맛보기)했다.

오늘(22일) 기준으로 다음 주에 중간 프로젝트가 있는 만큼 열심히 백엔드 개념을 익혀보기로 했다.

---

객체 지향 설계 개념에서 주요하게 배운 것은 "응집도 향상 전략" 과 "결합도 감소 전략" 이다.

이에 앞서 짚고 가야 할 것이 있는데, 그것은 바로 관심사에 따른 클래스의 분리이다.

 

객체 지향의 개념에서는 단일책임원칙(SRP, Single Responsibility Principle)이라는 것이 있다.

하나의 클래스나 메소드는 단 하나의 책임(역할)만을 가져야 한다는 말이다.

 

클래스 안에 다양한 책임(역할)이 존재한다면, 그것은 잘 된 객체 지향형 코드가 아니라는 것이다.

 

예를 들어보자. 

여기 사용자가 올린 텍스트 파일을 읽어와서 주어진 형식으로 파싱 후 화면에 띄워야 하는 서비스가 있다.

맨 처음 개발자는 이 모든 기능을 수행하는 textFile이라는 클래스를 만들었다.

현재 이 클래스는 위의 모든 책임(역할)을 수행하고 있다. 이는 객체 지향 설계 관점에서는 지양해야 하는 코드이다.

이를 단일 책임 원칙에 의거해서 리팩토링하면 다음과 같다.

* textFileUpload 클래스 : 사용자에게 파일을 받는 역할
* textFileRead 클래스 : 받은 파일 읽는 역할
* textFileParse 클래스 : 주어진 형식으로 파일 파싱하는 역할
* textFilePrint 클래스 : 파싱이 끝난 내용을 화면에 출력하는 역할

이런 식으로 클래스가 단일한 책임(역할)을 가지도록 분리하는 것이 단일 책임 원칙이다.

---

소프트웨어 공학을 공부하다보면 한번쯤 들어본 말이 있다.

" 응집도는 높게, 결합도는 낮게 하는 것이 좋은 프로그래밍 설계이다. "

 

여기서 말하는 응집도는 무엇이며, 결합도는 무엇일까?

응집도 : 한 모듈(클래스, 메소드 등) 내부의 처리요소들이 얼마나 서로 관련되어 있는 지
결합도 : 다른 모듈 간의 처리 요소가 얼마나 상호 의존 또는 연관되어 있는 지

 

객체 지향 관점에서 각 객체는 독립되어 있어야, 이 객체 지향 개념을 잘 수행하는 것이다.

 

따라서 객체 간의 의존도가 낮은, 다시 말해 결합도가 낮은 것이 좋은 코드라고 볼 수 있다. 

반면, 모듈 안의 코드들은 서로 관련성이 높은 것들 끼리만 묶여 있어야, 공통의 책임(관심사)로만 잘 분리한 모듈이기 때문에, 응집도는 높은 것이 좋은 코드인 것이다.

 

응집도 향상 전략에는 현재 모듈 안의 코드가 하나의 책임에만 관련된 코드인지 살피고, 아닌 코드가 있다면 별도의 모듈로 분리하는 것이다. 이렇게 분리하는 작업을 통해, SRP도 만족시키는 모듈 코드가 나올 수 있다.

 

결합도 감소 전략에는 대표적으로 추상화 작업이 있다.

이런 추상화 작업 중, 쉽게 작성해볼 수 있는 것이 인터페이스(Interface)를 활용하는 것이다.

A 클래스의 작업을 인터페이스로 추상화하면 이 A 클래스를 이용하는 B 클래스에서는 A 클래스와 직접 연결되어 있는 것이 아닌, A 클래스의 인터페이스라는 추상화된 단계를 거쳐서 연결된다. (아래 그림 참고)

이런 작업을 통해 A 클래스의 내부 코드가 많이 변동되어도, B 클래스는 이에 영향을 덜 받을 수 있다.

이처럼 모듈 간의 직접적인 결합을 낮추는 것이 결합도 감소 전략이다.

 

 

 

이런 전략 들로 우리는 더 좋은 품질의 코드를 만들 수 있다.

물론 처음 기능구현을 할 때부터 다 염두해두고 코드를 짜면 좋겠지만, 어렵다면 설계를 철저히 해보고,

이후 리팩토링 절차를 통해 단계적으로 코드 품질을 높이는 것도 방법이다.

---

막연하게 외웠던 응집도, 결합도 등 객체 지향 설계에 대한 개념이 보다 잘 이해되는 시간이었다.

앞으로의 작업은 코드 품질 향상에 많은 노력을 해야 겠다.