5. Phase 3 - 관심사 분리하기

1. BankStatementAnalyzer의 3가지 관심사

현재 BankStatementAnalyzer.java는 3가지 관심사를 가지고 있음

1. TSV 확장자(bank-data-simple.txt)로 작성된 입출금 내역 파일을 읽어들임
2. 조건에 따라 입출금 내역을 처리
3. 처리된 결과를 콘솔에 출력

→ 하나의 클래스가 너무 많은 기능(책임, Responsibility)을 담당하고 있는 상황

이처럼 혼자서 모든 일을 처리하고 있는 클래스를 God Class 라고 하며, 피해야 할 안티 패턴

1-1. 해결 방법

1. 소프트웨어 설계 원칙(SOLID ) 중 단일 책임 원칙(Single Responsibility Principle) 활용
   → 하나의 클래스나 메서드는 단 하나의 기능(책임)만 가질수록 좋음

1-2. 단일 책임 원칙(SRP)을 활용하여 BankStatementAnalyzer 클래스의 관심사를 분리

1. 주어진 입출금 내역 파일(bank-data.txt) 읽기
2. 주어진 형식(.TSV 확장자)으로 입력 변환(Parsing)
3. 입출금 내역 결과 처리
4. 콘솔에 결과 출력

→ 먼저 2번째 관심사인 TSV 파일을 파싱하는 로직을 현재 클래스에서 별도의 클래스로 책임을 분리

TSV 파일을 파싱하는 로직을 BankStatementAnalyzer.java에서 별도의 클래스인 BankDataTSVParser.java로 분리하였음

1-3. 적용 결과

적용 결과 개선된 포인트는 다음과 같음

명확한 역할 분리
클래스를 분리한 결과, Main 클래스인 BankStatementAnalyzer.java의 책임은 줄어들었고,
TSV 파일을 파싱하는 역할은 BankDataTSVParser.java가 담당하게 되었음

BankDataTSVParser는 .tsv 확장자 형태의 입출금 내역 데이터를 프로그램에서 읽어들일 수 있는 형태의 타입으로 변환(파싱)해주는 단 하나의 역할만 담당하고 있음
→ 단일 책임 원칙(SRP)이 적용되었고, 응집도(Cohesion) 또한 높은 상태

높아진 재사용성
BankDataTSVParser는 독립적으로 구현되어있기 때문에 추후 다른 클래스에서도 파싱 로직이 필요할 경우 캡슐화된 이 클래스를 가져다가 재사용할 수 있음

높아진 결합도(Side effect)
하지만 Main에서는 TSV 파일을 파싱하는 로직이 사라졌기 때문에, 해당 기능을 수행하기 위해서는 BankDataTSVParser에게 의존(dependent)하는 구조로 변화됨
→ BankStatementAnalyzer와 BankDataTSVParser 간 결합도(Coupling) 증가