[개발 일기] 2025.01.30 - 객체 지향 생활 체조 9가지 규칙 (1)

2025. 1. 30. 23:19·개발 일기

개요

 

오늘은 소트웍스 앤솔러지라는 개발서적에 있는 ‘객체 지향 생활 체조 원칙 9가지’에 대해 정리해 보자.

 

 

사실 위의 책을 읽진 않았지만, 숫자 야구라는 과제를 연습 삼아해 보다가 다양한 블로그에서 위 규칙을 토대로 코드를 짠 사람이 많길래 나

도 궁금해져서 이렇게 일기를 쓴다..!

 

 

 

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

 

위의 규칙이 만들어지게 된 계기는 클린 코드 작성과 객체 지향 원칙을 실천하기 위해서이다.

 

 

이 규칙을 지킨다면 더 객체 지향적이고 가독성이 뛰어난 코드를 만들 수 있다. (과연 내가 이걸 지킬 수 있을까..)

 

 

한 메서드에 오직 한 단계의 들여 쓰기만 허용한다

 

들여 쓰기가 많다는 것은 곧 코드의 복잡도가 높아진다는 의미고, 이는 하나의 메서드에서 너무 많은 역할을 하고 있을 가능성이 크다는 신호이다.

 

 

대표적인 예시가 중첩된 if문이나 반복문(for, while) 때문이다.

 

 

이는 코드의 유지보수 난이도를 높이고, 코드 재사용성을 떨어뜨리는 행동이다.

 

 

그렇기 때문에 한 메서드에 한 단계의 들여 쓰기만 허용한다는 것은 한 메서드는 하나의 작업만 담당하라는 의미와 동일한 것이다.

 

 

적용 전

 

public void processOrders(List<Order> orders) {
    for (Order order : orders) {
        if (order.isPaid()) {
            if (order.isShipped()) {
                System.out.println("완료된 주문: " + order.getId());
            } else {
                System.out.println("배송 대기 중: " + order.getId());
            }
        } else {
            System.out.println("결제 대기 중: " + order.getId());
        }
    }
}

 

 

적용 후

 

public void processOrders(List<Order> orders) {
    for (Order order : orders) {
        printOrderStatus(order);
    }
}

private void printOrderStatus(Order order) {
    if (!order.isPaid()) {
        System.out.println("결제 대기 중: " + order.getId());
        return;
    } else if (!order.isShipped()) {
        System.out.println("배송 대기 중: " + order.getId());
        return;
    }

    System.out.println("완료된 주문: " + order.getId());
}

 

 

 

else 예약어를 쓰지 않는다.

 

if - else if - else 이런 식으로 비교적 적은 조건 분기만 존재하는 경우는 당연히 어떤 조건을 토대로 나눠지는지 알기 쉽다.

 

 

하지만 여러 개의 조건이 중첩된 경우는 마지막 else가 어떤 의도를 가지는지 알기 어렵다.

 

 

그 이유는 else의 조건은 따로 개발자가 설정할 수 없기 때문이다.

 

if (...) {
    ...
} else if (...) {
    ...
} else if (...) {
    ...
} else if (...) {
    ...
} else { // 조건을 따로 설정할 수 없음
    ...
}

 

그렇기 때문에 조건분기의 마지막 else는 최대한 자제하는 것이 좋다.

 

 

적용 전

 

private String printOrderStatus(Order order) {
    if (!order.isPaid()) {
        return "결제 대기 중: " + order.getId();
    } else if (!order.isShipped()) {
        return "배송 대기 중: " + order.getId();
    } else {
        return "완료된 주문: " + order.getId();
    }
}

 

 

적용 후

 

private String printOrderStatus(Order order) {
    if (!order.isPaid()) {
        return "결제 대기 중: " + order.getId();
    } else if (!order.isShipped()) {
        return "배송 대기 중: " + order.getId();
    }
    
    return "완료된 주문: " + order.getId();
}

 

 

 

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

 

원시 값(int, double, boolean 등)만 덩그러니 놓여 있으면, 그 값이 어떤 역할을 하는지 확실하게 알기 힘들다.

 

 

물론 변수 명으로 판단이 가능하지만 이 보다 더 좋은 방법은 해당 원시 값을 객체로 감싸 의미를 부여하는 것이 더 좋다.

 

 

그 이유는 내가 작성한 코드를 보는 다른 개발자도 원시 값보단 객체 형태가 더 가독성이 좋을 것이고, 해당 객체가 관련된 로직을 모두 클래스 내부에 넣을 수 있기 때문이다.

 

 

적용 전

 

public class Main {
    public static void main(String[] args) {
        System.out.println(isAdult()); // false 출력
    }
    
    private static boolean isAdult() {
        int age = 15; // 원시 값 사용
        return age >= 18; // 성인 여부 판단 로직 포함
    }
}

 

 

적용 후

 

class Age {
    private final int age;
    private static final int ADULT_AGE = 18;

    public Age(int age) {
        if (age < 0) {
            throw new IllegalArgumentException("나이는 0 이상이어야 합니다.");
        }
        this.age = age;
    }

    public boolean isAdult() {
        return age >= ADULT_AGE;
    }
}

 

 

 

한 줄에 점을 하나만 찍는다

 

한 줄에 점이 많다는 것은 그만큼 의존하는 객체도 많아진다는 것이고 자연스럽게 결합도도 높아진 상태라는 것이다.

 

 

객체 지향 프로그래밍의 가장 중요한 원칙 중 하나가 응집도는 높이고, 결합도는 낮추는 것 이기 때문에 이 규칙을 웬만하면 지켜야 한다.

 

 

적용 전

 

public String getUserCity(User user) {
    return user.getAddress().getCity();
}

 

위의 메서드는 User가 조회하고자 하는 City 정보뿐만 아니라 Address까지 알아야 하는 상황이다.

 

 

적용 후

 

public String getUserCity(User user) {
    return user.getCity(); // User가 직접 city 정보를 제공
}

class User {
    private Address address;

    public String getCity() {
        return address.getCity(); // 내부에서 Address 정보를 감춤 (캡슐화)
    }
}

 

User 클래스 내부에서 City 정보를 제공하는 getCity() 메서드를 생성해 Address의 정보를 감추었다.

 

 

이를 통해 getUserCity() 메서드는 User 객체만 알면 City 정보를 조회할 수 있다.

'개발 일기' 카테고리의 다른 글

[개발 일기] 2025.02.01 - 객체 지향 생활 체조 9가지 규칙 (2)  (1) 2025.02.01
[개발 일기] 2025.01.31 - LSTM  (0) 2025.01.31
[개발 일기] 2025.01.29 - 불변 객체  (0) 2025.01.29
[개발 일기] 2025.01.28 - 이분탐색 (Lower Bound, Upper Bound)  (0) 2025.01.28
[개발 일기] 2025.01.27 - Nginx (Feat : Apache Web Server)  (0) 2025.01.27
'개발 일기' 카테고리의 다른 글
  • [개발 일기] 2025.02.01 - 객체 지향 생활 체조 9가지 규칙 (2)
  • [개발 일기] 2025.01.31 - LSTM
  • [개발 일기] 2025.01.29 - 불변 객체
  • [개발 일기] 2025.01.28 - 이분탐색 (Lower Bound, Upper Bound)
오도형석
오도형석
  • 오도형석
    형석이의 성장일기
    오도형석
  • 전체
    오늘
    어제
    • 분류 전체보기 N
      • MSA 모니터링 서비스
        • DB
      • 스파르타 코딩클럽
        • SQL
        • Spring
      • 백엔드
        • Internet
        • Java
        • DB
      • 캡스톤
        • Django
        • 자연어처리
      • Spring
        • JPA
        • MSA
      • ETC
        • ERROR
      • 개발 일기 N
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

  • 인기 글

  • 태그

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
오도형석
[개발 일기] 2025.01.30 - 객체 지향 생활 체조 9가지 규칙 (1)
상단으로

티스토리툴바