[객체지향 생활체조 원칙] 규칙 5. 줄여쓰지 않는다

줄여쓰지 않는다

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

숨은 의미

 왜 줄여쓰지 말아야 할까? 이 질문의 답은 '왜 줄이려고 하는가?' 라는 질문에서 시작할 수 있다. 축약을 하려는 이유는 간단하다. 이름이 너무 길고 복잡하기 때문이다. 복잡하고 긴 이름을 줄이기 위해 가장 먼저 단어의 길이를 줄이는 약어를 사용한다. 그러나 이 방법은 표현의 방법을 바꾸어 프로젝트에서 용어의 일관성과 명확한 의미전달에 문제를 야기할 수 있다.

 

 긴 이름을 줄여야 하는 이유는 단어가 가진 의미를 줄이는 데 있다. 일반적으로 이름이 길어진다는 것은 해당 변수, 메소드, 클래스에 많은 책임이 부여되어 있다는 것을 의미한다. 이번 규칙의 숨은 의미는 이름이 길어지면, 설계를 고민해보라는 뜻을 담고 있다. 이름이 길어지는 경우, 설계의 변경을 통해 한 이름이 표현하고자 하는 의미를 가볍게 만들어 보라는 것이다.

약어의 사용

 복잡하고 긴 이름을 보다 간단하게 표현하기 위해 약어를 사용하기도 한다. label -> lbl, apply -> aply 와 같은 형태이다. 또한 VIP와 같이 관용적으로 사용하는 축약어를 사용할 수도 있다. 약어를 사용하는 것이 무조건 나쁘다고 생각하지는 않는다. 영문단어 자체가 아주 긴 경우도 있고, 컴포넌트나 컨텍스트 영역을 표현할 때 약어 형태의 코드값을 활용하는 경우도 많기 때문이다. 또한 비즈니스 특성상 내부적으로 통용되는 신조어도 존재한다.

 

 실무의 프로그래밍은 혼자 하는 경우가 거의 없다. 설령 혼자 진행하더라도, 작성자가 해당 프로그램의 유지보수를 영원히 담당하는 경우는 거의 없다. 그렇기 때문에 약어를 사용하고자 할 때에는 약어를 관리할 수 있는 표준 용어관리 체계가 필요하다.

의미의 축약 - 메소드 분리

 축약은 의미를 단순화하는 방향으로 이루어져야 한다. 가장 먼저 할 수 있는 일은 메소드를 쪼개는 일이다.

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

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

 위 두 코드는 고객 객체의 속성인 이름과 나이를 변경하는 메소드를 보여주고 있다. modifyNameAndAge 라는 메소드는 이름부터 두 가지 이상의 책임을 지니고 있음을 명확히 드러낸다. 이렇게 여러 책임을 지니고 있는 메소드는 그 기능을 분리해 줌으로써 의미의 축약이 가능하다.

의미의 축약 - 시그니처 활용

public class Customer {

    private String name;
    private int age;
    ...
    
    public Customers findRelatedCustomers(String relationStatusCode) {
        // ...
    }
    
    public Customers findRelatedCustomers(String relationKindCode) {
        // ...
    }
  }

 위 코드는 연관고객들을 찾기 위한 메소드를 구현하고 있다. 두 메소드는 메소드 파라미터로 String 이라는 기본 자료형을 사용한다. 이런 경우 동일한 메소드명과 동일한 시그니처를 지니고 있으므로 컴파일 오류가 발생한다. 이를 해결하기 위해 다음과 같이 메소드 이름을 수정할 수 있다.

public class Customer {

    private String name;
    private int age;
    ...
    
    public Customers findRelatedCustomersByRelationStatus(String relationStatusCode) {
        // ...
    }
    
    public Customers findRelatedCustomersByRelationKind(String relationKindCode) {
        // ...
    }
  }

 메소드 이름을 사용해 컴파일 오류를 제거했다. 그런데 메소드명이 길어져버렸다. 이는 파라미터의 자료형이 메소드의 책임을 표현하는데 활용되고 있지 못하기 때문이다. 메소드의 파라미터로 원시 자료형을 사용하지 않고 별도의 클래스나 Enum 과 같이 비즈니스적 의미를 갖는 클래스를 활용하면 보다 간결한 표현을 할 수 있다.

public class Customer {

    private String name;
    private int age;

    public Customers findRelatedCustomers(CustomerRelationStatus relationStatus) {
        // ...
    }

    public Customers findRelatedCustomers(CustomerRelationKind relationKind) {
        // ...
    }
  }

 CustomerRelationStatus, CustomerRelationKind 는 별도의 비즈니스 로직을 담고있는 enum이다. 이와 같은 코드는 동일한 메소드명을 유지하면서도 시그니처를 통해 메소드의 책임을 표현할 수 있다. 또한 입력타입을 강제하므로, 런타임 오류가 발생할 가능성도 줄일 수 있다.

마치며

 '축약하지 않는다.' 라는 이번 주제도 클린코딩을 위한 습관이라기 보다는 객체지향 설계방법에 가깝다는 생각이 든다. 역할과 책임을 단순하게 구성한다는 방향으로 클래스의 매끄러운 설계에 대해 고민하다 보면 자연스럽게 이번 원칙을 지킬 수 있을 것이다.