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

개요

 

오늘은 객체 지향 생활 체조에서 남은 5가지 규칙을 정리해 보자.

 

 

 

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

 

줄여 쓰지 않는다

 

변수 명이나 메서드 명을 축약하지 않고, 의미가 명확하도록 작성한다.

 

 

보통 개발자가 메서드 명을 축약하고자 하는 경우는 하나의 메서드에서 너무 많은 역할을 수행해서일 경우가 크다.

 

 

그렇기 때문에 이 ‘줄여 쓰지 않는다’라는 규칙은 단일 책임 원칙과도 이어진다.

 

 

만약 하나의 메서드에서 하나의 역할만 담당한다면 자연스럽게 메서드 명은 짧아질 것이다.

 

 

적용 전

 

public class Board {
    ...
    public void modifyTitleAndContent(String title, String content) {
        ...
    }
}

 

 

적용 후

 

public class Board {
    ...
    public void modifyTitle(String title) {
        ...
    }
    
    public void modifyContent(String content) {
        ...
    }
}

 

 

 

모든 엔티티를 작게 유지한다

 

이 규칙은 단일 책임 원칙 그 자체의 규칙이다.

 

 

하나의 엔티티에 너무 많은 역할이 주어진 경우, 코드 라인 수는 자연스럽게 많아진다.

 

 

일반적으로 클래스의 길이는 200줄이 넘지 않도록 유지해야 한다.

 

 

 

3개 이상의 인스턴스 변수를 가진 클래스를 만들지 않는다

 

이 규칙은 처음에 보고 조금 의아했다. 아마 가장 지키기 어려운 규칙이 아닐까 싶다.

 

 

이 규칙의 의미는 원시형 타입이나 참조형 타입의 멤버 변수를 최대한 그대로 두지 말고, 의미가 겹치는 변수들끼리 모와 특정 클래스로 구현하라는 것이다.

 

 

적용 전

 

public class Member {
    private String name;      // 이름
    private int age;          // 나이
    private String email;     // 이메일
    private String address;   // 주소  -> 4개임. 규칙 위반!
    
    ...
}

 

 

적용 후

 

public class ContactInfo {
    private String email;
    private String address;

    ...
}

public class Member {
    private String name;
    private int age;
    private ContactInfo contactInfo; // 객체 분리

    ...
}

 

 

 

일급 컬렉션을 사용한다

 

일급 컬렉션이란 컬렉션을 감싸는 클래스를 만들고, 컬렉션을 클래스로 관리하는 방법을 의미한다.

 

 

이러한 규칙은 클린 아키텍처에서도 나왔던 방식이다. 확실히 좋은 방법인 듯하다. 

 

 

적용 전

 

public class Board {
    private String title;
    private String content;
    private List<String> comments; // 댓글
    
    ...
}

 

 

적용 후

 

public class Board {
    private String title;
    private String content;
    private Comments comments; // 댓글
    
    ...
}

public class Comments {
    private List<String> comments;
    
    ...
}

 

확실히 List <String> comments 보단 Comments comments 가 더 가독성이 좋다고 느껴진다.

 

 

그리고 Comments에 해당하는 정보들만 Comments 클래스에 둘 수 있기 때문에 ‘3개 이상의 인스턴스 변수를 가진 클래스를 만들지 않는다’ 규칙도 더 쉽게 지킬 수 있다.

 

 

 

setter/getter/property를 쓰지 않는다

 

객체의 상태를 직접 노출하지 말고, 객체 내부에서 데이터를 처리할 수 있도록 하여 캡슐화를 강화하고, 데이터 일관성을 유지하며, 결합도를 낮추기 위해 사용되는 규칙이다.

 

 

객체 내부의 데이터를 단순히 조회하는 것은 문제가 없다. 하지만 문제는 데이터를 조회한 후, 그 데이터를 수정할 때 발생한다.

 

 

객체 외부에서 객체가 예상치 못한 수정이 발생할 수 있기 때문에 웬만하면 데이터 수정은 객체 내에서 이루어져야 한다.

 

 

하지만 반드시 setter나 getter가 필요한 상황이 발생할 수 있다.

 

 

대표적으로 Spring JPA의 더티 체킹이다.

 

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    public void setName(String name) { // 더티체킹
        this.name = name;
    }
}

 

 

이런 식으로 어쩔 수 없이 setter 사용이 필요한 경우엔, 메서드 명을 적절히 수정해야 한다.

 

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String name;

    public void changeName(String newName) { // setter X
        validateName(newName);
        this.name = newName;
    }
}

 

 

위와 같이 setterName()을 changeName()으로 변경해 의미를 더욱 확실히 하는 것도 하나의 방법이 될 수 있다.