개발자일걸요?

검색

SearchSearch

최근 글

메서드 네이밍: 부작용 유무에 따른 구분과 모범 사례

2024년 8월 28일10 min read

주의

  • 본 게시글은 Claude로 작성되었습니다. 잘못된 정보가 있을 수 있습니다.

개요

메서드 네이밍은 코드의 가독성과 유지보수성에 큰 영향을 미치는 중요한 요소입니다. 특히 메서드가 부작용(side effect)을 가지고 있는지 여부를 이름에 반영하는 것은 매우 중요합니다. 이 문서에서는 부작용이 있는 메서드와 없는 메서드의 네이밍 컨벤션을 비교하고, 효과적인 네이밍 전략을 제시합니다.

부작용이란?

부작용은 메서드가 자신의 스코프 외부의 상태를 변경하는 것을 의미합니다. 예를 들어, 객체의 필드를 수정하거나, 데이터베이스를 업데이트하거나, 파일을 쓰는 등의 작업이 부작용에 해당합니다.

부작용 유무에 따른 메서드 네이밍 전략

1. 부작용이 없는 메서드 (순수 함수)

  • 특징: 동일한 입력에 대해 항상 동일한 출력을 반환하며, 외부 상태를 변경하지 않습니다.
  • 네이밍 전략: 명사, 명사구, 또는 형용사구를 사용합니다.
  • 예시:
    • sum()
    • absoluteValue()
    • isPrime()
    • toLowerCase()

2. 부작용이 있는 메서드

  • 특징: 외부 상태를 변경하거나, 동일한 입력에 대해 다른 결과를 반환할 수 있습니다.
  • 네이밍 전략: 동사 또는 동사구를 사용하며, 상태 변경을 암시하는 단어를 포함합니다.
  • 예시:
    • save()
    • update()
    • delete()
    • sendEmail()

3. 특별한 경우: 상태를 조회하고 변경하는 메서드

일부 메서드는 상태를 조회하면서 동시에 변경할 수 있습니다. 이런 경우, 두 동작을 모두 나타내는 이름을 사용합니다.

  • 예시:
    • getAndIncrement()
    • checkAndSet()

네이밍 패턴 비교

부작용 없음부작용 있음설명
get...set...값을 조회 vs 값을 설정
calculate...update...값을 계산 vs 상태를 업데이트
find...save...항목을 검색 vs 항목을 저장
is...ensure...상태 확인 vs 상태 보장

사용 예제

다음은 부작용 유무에 따른 메서드 네이밍의 예시입니다:

public class UserService {
    private UserRepository userRepository;
 
    // 부작용 없음: 단순히 값을 반환
    public boolean isEmailValid(String email) {
        return email.matches("^[A-Za-z0-9+_.-]+@(.+)$");
    }
 
    // 부작용 있음: 데이터베이스 상태 변경
    public void saveUser(User user) {
        userRepository.save(user);
    }
 
    // 부작용 없음: 새 객체 생성 및 반환
    public User mergeUsers(User user1, User user2) {
        return new User(user1.getName() + " " + user2.getName());
    }
 
    // 부작용 있음: 객체 상태 변경
    public void updateUserEmail(User user, String newEmail) {
        user.setEmail(newEmail);
    }
 
    // 부작용 있음: 조회 및 상태 변경
    public User getAndIncrementLoginAttempts(String username) {
        User user = userRepository.findByUsername(username);
        user.incrementLoginAttempts();
        return user;
    }
}

모범 사례 및 팁

  1. 일관성 유지: 프로젝트 전체에서 일관된 네이밍 컨벤션을 사용하세요.

  2. 명확성 우선: 간결성보다는 명확성을 우선시하세요. processData()보다는 validateAndSaveUserData()가 더 명확합니다.

  3. 부작용 최소화: 가능한 한 부작용이 없는 순수 함수를 사용하세요. 이는 코드의 테스트와 유지보수를 더 쉽게 만듭니다.

  4. 명령-쿼리 분리: 가능한 한 상태를 변경하는 메서드(명령)와 값을 반환하는 메서드(쿼리)를 분리하세요.

  5. 문서화: 복잡한 부작용이 있는 경우, JavaDoc 주석을 사용하여 메서드의 동작을 명확히 설명하세요.

결론

메서드 네이밍에서 부작용 유무를 구분하는 것은 코드의 예측 가능성과 유지보수성을 크게 향상시킵니다. 부작용이 없는 메서드는 주로 명사나 형용사를 사용하고, 부작용이 있는 메서드는 동사를 사용하여 상태 변경을 암시합니다. 이러한 네이밍 컨벤션을 일관되게 적용함으로써, 개발자들은 코드를 더 쉽게 이해하고 효과적으로 사용할 수 있습니다.

참조

FAQ

Q: 부작용이 있는 메서드와 없는 메서드를 같은 클래스 내에 혼용해도 괜찮을까요?

A: 네, 가능합니다. 하지만 메서드의 책임을 명확히 구분하고, 네이밍을 통해 부작용의 유무를 명확히 표현하는 것이 중요합니다. 가능하다면 부작용이 있는 메서드와 없는 메서드를 분리된 클래스나 인터페이스로 구분하는 것도 좋은 방법입니다.

Q: 부작용이 있는 메서드의 반환 값은 어떻게 처리해야 할까요?

A: 부작용이 있는 메서드의 반환 값은 주의해서 다뤄야 합니다. 일반적으로 상태 변경의 결과나 성공/실패 여부를 반환합니다. 예를 들어, boolean updateUserProfile(User user)와 같이 작업의 성공 여부를 반환하거나, User saveUser(User user)처럼 업데이트된 엔티티를 반환할 수 있습니다.

Q: 불변 객체를 다루는 메서드도 부작용이 있다고 볼 수 있나요?

A: 불변 객체를 다루는 메서드는 일반적으로 부작용이 없다고 간주됩니다. 예를 들어, String 클래스의 toUpperCase() 메서드는 새로운 String 객체를 반환하며 원본 객체를 변경하지 않습니다. 이는 부작용이 없는 메서드의 좋은 예시입니다.

Q: 비동기 메서드의 네이밍은 어떻게 해야 할까요?

A: 비동기 메서드의 경우, 메서드 이름 뒤에 ‘Async’를 붙이는 것이 일반적입니다. 예를 들어, fetchUserDataAsync(), saveUserAsync() 등입니다. 또한 CompletableFuture나 리액티브 프로그래밍을 사용할 경우, getUserFuture(), saveUserMono() 등의 네이밍 패턴을 사용할 수 있습니다.

관련 질문 및 추가 정보

  • 함수형 인터페이스와 부작용: Java 8에서 도입된 함수형 인터페이스(예: Function, Predicate, Consumer 등)를 사용할 때 부작용 처리는 어떻게 해야 할까요? 함수형 프로그래밍의 원칙과 Java의 객체지향적 특성을 어떻게 조화롭게 사용할 수 있을까요?

  • 트랜잭션과 부작용: 데이터베이스 트랜잭션을 다루는 메서드의 네이밍은 어떻게 해야 할까요? 트랜잭션 내에서 여러 부작용이 발생할 때, 이를 메서드 이름에 어떻게 반영할 수 있을까요?

  • 테스트 용이성과 네이밍: 부작용이 있는 메서드와 없는 메서드의 테스트 방식은 어떻게 다른가요? 테스트 용이성을 고려한 메서드 네이밍 전략은 무엇일까요?

  • 도메인 주도 설계(DDD)와 메서드 네이밍: DDD의 컨텍스트에서 부작용이 있는 메서드와 없는 메서드의 네이밍은 어떻게 접근해야 할까요? 예를 들어, 애그리게이트 루트의 메서드 네이밍은 어떤 원칙을 따라야 할까요?

  • 성능 최적화와 부작용: 캐싱이나 지연 로딩(lazy loading)과 같은 성능 최적화 기법을 사용할 때, 이로 인한 부작용을 메서드 이름에 어떻게 반영할 수 있을까요?

  • 로깅과 부작용: 로깅을 수행하는 메서드도 부작용이 있다고 볼 수 있을까요? 로깅이 포함된 메서드의 네이밍은 어떻게 해야 할까요?

이 페이지에 대한 링크

그래프 뷰