핀수로그
  • [아무튼 필사] 내 코드가 그렇게 이상한가요? 4일차
    2023년 12월 21일 14시 03분 03초에 업로드 된 글입니다.
    작성자: 핀수
    728x90
    반응형

    5장 응집도 : 흩어져 있는 것들

    응집도(cohesion) 란 '모듈 내부에 있는 데이터와 로직 사이의 관계가 얼마나 강한지 나타내는 지표입니다. 모듈을 클래스, 패키지, 레이어 등을 모두 포함할 수 있는 용어입니다. 이 책에서는 쉽게 이해할 수 있게 모듈을 클래스라고 생각하겠습니다. 따라서 응집도를 '클래스 내부에 있는 데이터와 로직 사이의 관계가 얼마나 강한지 나타내는 지표'로 설명하겠습니다.

    응집도가 높은 구조는 변경하기 쉬우며, 바람직한 구조입니다. 반대로 응집도가 낮은 구조는 변경 시 문제가 발생하기 쉽습니다.

    응집도가 낮은 구조의 대표적인 예로 데이터 클래스를 소개했습니다. 하지만 데이터 클래스 이외에도 응집도를 낮추는 악마들이 있습니다.

    ...

    5.3 범용 처리 클래스 (Common/Util)

    static 메서드를 빈번하게 볼 수 있는 클래스로, 범용 처리를 위한 클래스가 있습니다. 일반적으로 이러한 클래스에는 Common, Util이라는 이름이 붙습니다. 문제는 static 메서드와 마찬가지로 응집도가 낮은 구조가 만들어질 수 있다는 것입니다. 이는 더 나쁜 악마를 불러들일 수 있습니다.

    똑같은 일을 수행하는 코드가 많아지면 코드를 재사용하기 위해 범용 클래스를 만들곤 합니다. 이때 static 메서드로 구현되는 경우가 많습니다.

    ...

    5.3.1 너무 많은 로직이 한 클래스에 모이는 문제

    public class Common {
        // 생략
    
        // 세금 포함 금액 계산하기
        static BigDecimal calAmountIncludingTax(BigDecimal amountExcludingTax, BigDecimal taxRate) { ... }
    
        // 사용자가 이미 탈퇴했다면 true
        static boolean hasResigned(User user) { ... }
    
        // 상품 주문하기
        static void createOrder(Product product) { ... }
    
        // 유효한 전화번호라면 true
        static boolean IsValidPhoneNumber(String phoneNumber) { ... }
    }

     

    세금을 계산하는 메서드 이외에도 탈퇴했는지 확인하는 메서드, 주문 메서드처럼 관련이 없는 로직이 Common 클래스 안에 모여 있습니다. 심지어 모두 static 메서드입니다. 이는 응집도가 낮은 구조입니다. 안타깝게도 이런 코드는 실제 프로덕션 코드에서도 굉장히 많이 볼 수 있습니다.

    어째서 이런 일이 일어나는 것일까요?

    원인은 Common과 Util이라는 이름 자체가 '범용'이라는 뜻이기 때문입니다.

    이 이름은 읽는 사람에게 '범용적으로 사용하고 싶은 로직은 Common 클래스에 모아 두면 되겠구나'라고 생각하게 만듭니다.

    근본적인 원인은 범용의 의미와 재사용성을 잘못 이해하고 있기 때문입니다. 재사용성은 설계의 응집도를 높이면, 저절로 높아집니다.

     

    5.3.2 객체 지향 설계의 기본으로 돌아가기

    꼭 필요한 경우가 아니면, 범용 처리 클래스를 만들지 않는 것이 좋습니다.

    ...

     

    5.3.5 횡단 관심사

    로그 출력과 오류 확인은 애플리케이션의 모든 동작에 필요한 기능입니다. 온라인 쇼핑몰에서도 주문, 예약, 배송 같은 모든 상황에 필요한 기본 기능일 것입니다.

    이처럼 다양한 상황에서 넓게 활용되는 기능을 횡단 관심사(cross-cutting concern)라고 부릅니다. 대표적으로 다음과 같은 기능들을 들 수 있습니다.

    • 로그 출력
    • 오류 확인
    • 디버깅
    • 예외 처리
    • 캐시
    • 동기화
    • 분산 처리

    횡단 관심사에 해당하는 기능이라면 범용 코드로 만들어도 괜찮습니다. 

     


    이번 글은 늘 그랬지만 정말로 내가 자주 범했던? 실수여서 이 단락을 정해보았다.

    자주 쓰는 메서드를 Util 클래스에 넣어두면..편하니까..라는 마법에 속아 관련 없는 코드를 한데 모아두곤 했었다.

    역시 좋은 설계라는 것은 초반에는 공을 많이 들여야하지만 뒤로 갈수록 편해지고 (유지보수가 용이해지니)

    쉽게 작성된 코드는 초반에는 별 무리 없이 작성되었겠지만 뒤로 갈수록 불편함이 눈덩이처럼 불어나는 것 같다.

     


    출처

     

    내 코드가 그렇게 이상한가요?

    공감 100% 나쁜 코드 사례로 배우는 지속 가능한 코드 설계 입문서. 객체 지향 설계를 통해 코드 품질을 높이는 방법을 설명한다. 설계를 고민하지 않고 작성한 코드는 오로지 한 치 앞만 바라본

    www.aladin.co.kr

     

    728x90
    반응형
    댓글