[Java] 객체지향 생활체조 원칙 9가지에 대해 알아보자

객체지향 생활체조 9가지 원칙

소트웍스 앤솔러지

책 소트웍스 앤솔러지에 나오는 '객체지향 생활체조 원칙'에 대해 알아봅시다.

누구나 객체지향 설계를 잘하고 있다고 생각할 수 있지만, 무의식적으로 버리기 힘든 습관들로 인해 '좋은 설계'의 바탐이 되는 핵심 개념들(응집도, 결합도, 중복, 캡슐화, 테스트 가능성, 가독성, 초점)을 놓치는 경우가 많습니다.

 

책에 서술된 원칙들을 통해 좋은 객체지향 설계의 원칙을 알아보겠습니다.

 

책에는 총 9가지의 원칙이 서술되어 있습니다.

 

<규칙>

1. 한 메소드에는 오직 한 단계의 들여쓰기만 한다.
2. else 예약어를 쓰지 않는다.
3. 모든 원시 값과 문자열을 포장한다.
4. 한 줄에 점을 하나만 찍는다.
5. 줄여쓰지 않는다(축약 금지).
6. 모든 엔티티를 작게 유지한다.
7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
8. 일급 컬렉션을 사용한다.
9. getter, setter, property를 쓰지 않는다.

---

1. 한 메소드에는 오직 한 단계의 들여쓰기만 한다.

볼륨이 큰 메소드는 응집도가 떨어지기 마련입니다. 따라서 하나의 메소드는 하나의 일만 담당하도록 하는 것이 좋습니다.

메소드에 한 가지 일만 담당하도록 설정하면 애플리케이션의 유닛이 더 작아짐에 따라 재사용의 수준은 올라가고, 유지보수의 장점도 가져갈 수 있습니다.

• 1개의 메소드 안에서 if / for / while 등을 2 depth 이상 사용하지 않기

잘못된 예시 코드

public class Book {
    private char[][] data = new char[10][10];

    public Book(char[][] data) {
        this.data = data;
    }
    private String readBook() {
        StringBuffer buf = new StringBuffer();
        for (int i = 0; i < 10; i++) { // 1
            for (int j = 0; j < 10; j++) { // 2
                buf.append(data[i][j]);
            }
        }
        return buf.toString();
    }
}

• readBook() 메소드를 보면 for문에서 들여쓰기가 2 depth 까지 올라간 것을 볼 수 있습니다.

수정된 예시 코드

public class Book {
    private char[][] data = new char[10][10];

    public Book(char[][] data) {
        this.data = data;
    }
    private String readBook() {
        StringBuffer buf = new StringBuffer();
        for (int i = 0; i < 10; i++) { // 1
            readLine(buf, i);
        }
        return buf.toString();
    }

    private void readLine(StringBuffer buf, int i) {
        for (int j = 0; j < 10; j++) { // 2
            buf.append(data[i][j]);
        }
    }
}

• 이렇게 각각의 메소드의 들여쓰기가 1 depth 를 넘어가지 않도록 함으로써, 높은 가독성과 재사용성을 가져갈 수 있습니다.
• 뿐만 아니라 이와 같이 리펙토링하면 코드의 버그를 찾기도 대체로 쉬워집니다.

 

>>>>>>>>>> indent는 1 depth를 넘어가지 않도록 하자.

---

2. else 예약어를 쓰지 않는다.

if/else 구문은 모든 언어가 가지고 있지만, 여러 겹으로 중첩된 조건문을 접할 경우 else가 있는 코드는 의도를 파악하기 어렵습니다.

이러한 경우에 대비하여 else문을 사용하지 않고 if 조건에 만족하면 if 실행문으로 메소드를 종료되고, 나머지 코드는 기본 로직을 따라가는 방법을 쓸 수 있습니다.

 

잘못된 예시 코드

public void login(String username, String password) {
    if (userRepository.isValid(username, password)) {
        redirect("homePage");
    } else {
        redirect("errorPage");
    }
}

public class Calculator {

    private int calculate(int a, int b, String op) {
        if (op.equals("*")) {
            return a * b;
        } else {
            return a + b;
        } 
    }
}

위와 같은 코드의 else문은 early return 문을 통해 아래와 같이 해결할 수 있습니다.

 

수정한 예시 코드

public void login(String username, String password) {
    if (userRepository.isValid(username, password)) {
        redirect("homePage");
    }
    
    redirect("errorPage");
}

public class Calculator {

    private int calculate(int a, int b, String op) {
        if (op.equals("*")) {
            return a * b;
        } 
        return a + b;
    }
}

• 이렇게 리펙토링하여 자연스럽게 가독성이 증가했고, 이해하기도 쉬워졌습니다.

• 뿐만 아니라 이렇게 else문을 사용하지 않으면, optimistic(if문을 통해 기본 시나리오를 따르게 하는 조건을 설정)하고, defensive(기본 시나리오에 충족하지 않으면 오류 상태를 반환하도록)하게 접근할 수 있습니다.

 

>>>>>>>>>>> else 키워드 사용금지

---

3. 모든 원시값과 문자열을 포장한다.

모든 원시값(primitive)을 객체로 포장(wrapper)하는 것이다. 원시형 데이터는 변수명으로서만 그 의미를 추론할 수 있고 아무런 의미를 담고 있지 않습니다. 하지만 원시값을 클래스로 감싼다면 그 데이터가 무엇인지, 그리고 왜 사용해야 하는지를 보다 명확하게 전달할 수 있다. 

 

예를 들면, int 값 하나 자체는 아무 의미없는 스칼라 값일 뿐이지만 이 변수를 객체로 래핑하면 얻을 수 있는 이점이 많습니다.

 

기존 코드

private static int sum(int[] numArray) {
    int result = 0;
    for(int i = 0; i < numArray.length; i++) {
        int num = numArray[i];
        if(num < 0) {
            throw new RuntimeException();
        }
        result += num;
    }
    return result;
}

수정된 코드

public class Positive {
    private int number;

    public Positive(int number) {
        if (number < 0) {
            throw new RuntimeException();
        }
        this.number = number;
    }

    public Positive add(Positive other) {
        return new Positive(this.number + other.number);
    }

    public int getNumber() {
        return number;
    }
}

private static Positive[] toPositives(int[] values) {
    Positive[] numbers = new Positive[values.length];
    for (int i = 0; i < values.length; i++) {
        numbers[i] = new Positive(values[i]);
    }
    return numbers;
}

private static int sum(Positive[] numbers) {
    Positive result = new Positive(0);
    for (Positive number : numbers) {
        result = result.add(number);
    }
    return result.getNumber();
}

• 원시타입인 int를 Positive 객체로 래핑함으로써, 도메인에서 값을 스스로를 검증하도록 할 수 있습니다. 이와 같은 래핑은 상위 클래스에 과도한 책임을 주는 것을 막고 추가적인 요구사항에 대응하기 편리해도록 합니다.
• 이러한 클래스 분리는 객체 지향적인 코드를 유도하고 SOLID의 SRP, OCP도 만족할 수 있게 돕습니다.

 

 

>>>>>>>>>>> 원시적인 타입 사용을 지양하고, 래핑하여 객체로 사용하는 것을 지향하자.

---

4. 한 줄에 점 하나만 찍는다.

점은 자바에서 메소드를 호출할 때 사용하는 키워드입니다. 점을 이용해 메소드를 호출할 때, 객체 그래프를 따라 멀리 떨어진 객체에게 메시지를 보내는 설계를 지양하라는 원칙입니다. 

 

이와 같은 설계는 거의 모든 객체간 결합도가 생기게 되고 캡슐화가 깨지게 됩니다.

 

기존 코드

if(user.getMoney().getValue() > 100_000L) {
    throw new IllegalArgumentException("소지금은 100_000원을 초과할 수 없습니다.");
}

이 코드에서는 User, Money 두 객체에 의존하게 됩니다.

 

수정된 코드

if(user.hasMoney(100_000L)) {
    throw new IllegalArgumentException("소지금은 100_000원을 초과할 수 없습니다.");
}

• 이와 같이 리펙토링하면 User 객체에게만 의존하게 하여, 이 코드에서 getMoney를 직접 수행하는 것이 아닌 단지 User에게 물어보게 할 수 있습니다.

 

기존 코드

private boolean isEqualToPostWriter(Member receiver, Post post) {
    return post.getMember().getNickname().equals(receiver.getNickname());
}

• 해당 메소드를 사용하는 서비스 클래스에서는 post 뿐만 아니라, member에도 의존하게 됩니다.

수정한 코드

public boolean isOwnerEqualToNickname(String nickname) {
    return this.getMember().getNickname().equals(nickname);
}

Post Entity에 위와 같이 메소드를 작성하여 책임을 분리할 수 있습니다.

private boolean isEqualToPostWriter(Member receiver, Post post) {
    return post.isOwnerEqualToNickname(receiver.getNickname());
}

책임을 분리하여 서비스 클래스에서는 post에만 의존하게 하여 결합도를 낮출 수 있습니다.

 

 

>>>>>>>>>>> 객체를 통해 너무 먼 객체를 불러와서 사용하는 것을 지양하는 습관을 가지자.

---

5. 줄여쓰지 않는다. (축약 금지)

 

만약 클래스나 메서드에 붙일 적당한 이름을 찾지 못한다면 뭔가 잘못되었을 가능성이 높다.

즉 클래스나 메서드에 명확한 이름을 붙일 수 있으려면 그 역할과 책임이 단순해야 한다. 

 

클래스, 메소드, 변수 명명시 축약을 하지 말자는 규칙입니다.

 

객체지향 세계에서는 클래스명이나 필드명, 메소드명을 축약할 필요가 없습니다. 

축약하려는 이유는 메소드의 이름이 길어지기 때문이라고 할 수 있는데, 아마 그렇다면 그 메소드는 많은 책임을 안고 있을 확률이 높습니다.

책임을 분리하는 습관을 가집시다.

 

 

기존 코드

 

public void example() {
        Customer customer = new Customer();
        customer.modifyNameAndAge("변경후이름", 20);
}

수정된 코드

public void example() {
    Customer customer = new Customer();
    customer.modifyName("변경후이름");
    customer.modifyAge(20);
}

 

>>>>>>>>>>> 책임을 분리한다면, 이름을 굳이 축약하려고 하지 않아도 이름이 깔끔해진다. 책임을 분리하는 습관을 가지자.

---

6. 모든 Entity는 작게 유지한다.

엔티티를 작성할 때 하나의 목적을 염두하고 설계하라는 의미입니다. SOLID 원칙중 단일 설계 원칙인 SRP와 연계되는 규칙입니다.

클래스의 크기를 줄여 분리하기 시작하면, 작은 역할을 하게 될 것입니다. 

 

하나의 Class는 50줄을 넘기지 않기를 권장합니다. 구현에 따라 달라지겠지만, 하나의 클래스가 100 line을 넘어간다면 분명 분리해낼 수 있을 것입니다. 또한 하나의 패키지에는 10개 이상의 파일이 담기지 않기를 권장합니다. 클래스 뿐만 아니라 패키지도 클래스처럼 응집력 있고 단일한 목표가 있어야 합니다. 패키지를 작게 유지함으로 패키지 자체로 정체성을 지닐 수 있게 됩니다.

 

 

>>>>>>>>>>> 하나의 클래스는 50 line 이상, 하나의 패키지는 10개 이상의 파일이 묶이지 않도록 하자. 클래스 분리를 두려워하지 말자.

---

7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

클래스의 인스턴스 변수를 제한하라는 의미입니다. 여기서 인스턴스 변수는 원시(primitive)타입이나 컬렉션과 같이 기본 또는 자료구조형의 변수를 의미합니다.

 

도메인 요소들을 어떻게 묶고 구성할 것인지 그 설계에 대해 충분히 고민하여 클래스를 구성하고, 리팩토링 하라는 규칙입니다. 

이 지침은 3번 규칙과도 통하는 규칙으로, 원시값을 객체로 포장하여 도메인적 의미를 부여하라는 가이드라고 할 수 있습니다.

 

 

 

기존 코드

class Name {
    String firstName;
    String lastName;
    // ... 성과 이름에 대한 기능
}

수정된 코드

public class Name {
    FirstName firstName;
    LastName lastName;
}

class FirstName {
    String name;
    // ... 이름에 대한 기능
}

class LastName {
    String name;
    // ... 성에 대한 기능
}

이 효과로 6번 규칙을 지키는 것과 같은 효과도 얻을 수 있습니다. 

 

>>>>>>>>>>> 클래스는 분류할 수 있으면 최대한 분류하자.

---

8. 일급 컬렉션을 사용하자.

컬렉션을 Wrapping하면서 Collection 외 다른 필드를 가지고 있지 않은 클래스를 일급컬렉션이라고 합니다.

public class Store {
    private Set<Brand> brands; // 컬렉션

    public Store(List<Brand> brands) {
        validSize(brands);
        this.brands = brands;
    }

    private void validSize(List<Brand> brands) {
        if(brands.size() >= 10) {
            throw new IllegalArgumentException("브랜드는 10개 초과로 입점할 수 없습니다.");
        }
    }
}

Store와 같이 일급 컬렉션을 사용하면, 컬렉션을 사용하는 클래스 Brand에서 검증하지 않고 위와 같이 일급 컬렉션 Store에서 자율적으로 검증할 수 있습니다.

 

뿐만 아니라 일급 컬렉션을 사용하면 

Set<Brand> brands; -> Store store; 로 사용이 가능한데, 클래스 타입을 명시해줌으로써, 비즈니스적 의미를 표현할 수 있을 뿐더러, 클래스를 사용하는 코드에 Set이 아닌 Store로 명시함으로 시그니처로 제약을 줄 수 있습니다. 즉, 더욱 명확한 비즈니스적 표현을 할 수 있습니다.

 

>>>>>>>>>>  일급컬렉션은 '복수형 클래스' 를 표현하기 위한 좋은 방법을 제시합니다. 단일 인스턴스가 집합을 이루면서 가질 수 있는  비즈니스적 의미에 대해 고민해보면 더욱 다채로운 설계를 할 수 있을 것입니다.

---

9. setter, getter, property를 쓰지 않는다.

Entity에 getter/setter/property 사용을 지양해 객체 상태 노출을 최소화 하라는 규칙입니다.

 

즉, 객체지향 프로그래밍의 핵심 개념 중 캡슐화를 지키면서 객체에 메시지를 보내 스스로 상태에 대한 처리로직을 수행하도록 하라는 의미로 객체의 상태를 가져오는 접근자를 사용하는 것은 괜찮지만, 그 상태를 객체 바깥에서 변경하면 안된다는 것입니다. 한 객체의 상태에 대한 결정은 반드시 객체 안에서 이루어져야 합니다.

 

주의 : 이 지침은 데이터 전달을 목적으로 하는 DTO나 프로세스 처리를 목적으로 하는 컨트롤러, 서비스 빈 클래스를 대상으로 하지 않는다.

 

기존 코드

 

public class VipMemberService {

    private static final BigDecimal VIP_DEPOSIT_AMOUNT = new BigDecimal("1000000000");

    public void saveBenefit(Member member) {
        if (VIP_DEPOSIT_AMOUNT.compareTo(member.getTotalDepositAmount()) > 0) {
            throw new IllegalStateException("VIP 고객이 아닙니다.");
        }
        // ...
    }
}

•  위 코드의 문제
  • Member 클래스가 가진 정보를 직접 꺼내 판단을 위한 근거로 사용됨.
  • 코드를 이렇게 구현할 경우, VIP 판별 기준이 DepositAmount이 아닌 다른 프로퍼티로 변경되면 서비스 계층에서 member.getTotalDepositAmount() 부분을 전부 다 변경주어야 한다는 것입니다.
  • 뿐만 아니라 Member 클래스의 정보를 꺼내 비교하는 것 외에 어떤 비즈니스적 의미를 표현하지 못한다는 것입니다. (가독성이 낮아진다.)

 

수정한 코드

public class VipMemberService {

    public void saveBenefit(Member member) {
        if (!member.isVip()) {
            throw new IllegalStateException("VIP 고객이 아닙니다.");
        }
        // ...
    }
}

• getter를 제거한 코드.
• 조건문의 문장을 굳이 해석할 필요가 없어졌고, 코드가 직관적으로 변경됨.

객체의 정보는 이렇게 객체에서 직접 처리하도록 구현하여야 합니다. 특히 조건문의 활용에서 이와 같은 실수가 많은데, 조건문을 사용하려는 본래의 목적에 집중한다면, 자연스럽게 조건문의 판별 기준이 클래스의 내부로 이동할 것입니다.

 

>>>>>>>>>>> getter, setter를 지양하고 객체의 상태는 객체 내부에서 처리하도록 지향하자.

---

 

<참고 자료>

 

더 나은 소프트웨어를 향한 9단계: 객체지향 생활 체조(1)

 

객체지향 생활체조 원칙 (Object Calisthenics)

객체지향 생활 체조 원칙 9가지 정리!

 

[객체지향 생활체조 원칙] 규칙 8. 일급 컬렉션을 쓴다