Skip to content

Latest commit

 

History

History
137 lines (97 loc) · 5.58 KB

68_일반적으로_통용되는_명명_규칙을_따르라_신선영.md

File metadata and controls

137 lines (97 loc) · 5.58 KB

item 68. 일반적으로 통용되는 명명 규칙을 따르라

🐹 명명 규칙

  • 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다.
  • 특별한 이유가 없으면 반드시 따르는 것이 좋다.
    • 그렇지 않으면 유지보수가 어려워지고, 의미를 오해할 수 있어 오류 발생 가능성이 높아진다.

패키지와 모듈

  • 요소를 온점(.)으로 구분하여 계층을 짓는다.
  • 요소들은 소문자 알파벳과 (드물게) 숫자로 이뤄진다
  • 조직의 도메인 이름을 역순으로 한다.
    • org.apache.commons.lang3.StringUtils
    • 예외적으로 표준 라이브러리와 선택적 패키지들은 java, javax로 시작한다.
      • java.time.LocalDate
  • 각 요소는 일반적으로 8글자 이하의 짧은 단어로 짓는다.
    • java.utilities.Objects (X)
    • java.util.Objects (O)

클래스와 인터페이스

  • 하나 이상의 단어로 이루어지며, Pascal Case로 작성한다.
    • StringUtils
  • 널리 통용되는 약어가 아니라면 줄여쓰지 않는다.
    • 만약 널리 통용되는 약어라면 첫 글자만 대문자로 표기한다.
      • HTTPURL (X)
      • HttpUrl (O)

메서드와 필드

  • 하나 이상의 단어로 이루어지며, Camel Case로 작성한다.
    • isEmpty
  • 상수 필드는 예외로, 모두 대문자로 작성하며 단어 사이는 언더바(_)로 구분한다.
    • INDEX_NOT_FOUND

타입 매개 변수

  • 보통 한 문자로 표현한다.
    • T(ype) : 임의의 타입,
    • E(lement) : 컬렉션 원소의 타입
    • K(ey) - Value : 맵의 키와 값
    • (e)X(ception) : 예외
    • R(eturn) : 메서드의 반환 타입

🐔 문법 규칙

인스턴스화 가능한 클래스, Enum

  • 보통 단수 명사, 명사구를 사용한다.
    • AppType

인스턴스화가 불가능한 클래스

  • 보통 복수 명사를 사용한다.
    • Collectors

어노테이션

  • 규칙이 따로 없어 명사, 형용사, 동사, 전치사가 두루 쓰인다.
    • Singleton, Inject

인터페이스

  • 보통 단수 명사, 명사구를 사용한다.
    • Comparator
  • ~able, ~ible로 끝나는 형용사를 사용하기도 한다.
    • Runnable

메서드

  • 동사나 동사구를 사용한다.
  • boolean을 반환한다면 is~, (드물게) has~로 시작하고, 명사, 명사구, 형용사로 끝난다.
    • isEmpty
  • boolean을 반환하지 않거나 인스턴스의 속성을 반환한다면 명사, 명사구, 혹은 get으로 시작하는 동사구를 사용한다.
    • getAge, size

특별한 메서드

  • 타입을 바꿔서 다른 객체의 객체를 반환하는 메서드는 to~
    • toString
  • 객체의 내용을 다른 뷰로 보여주는 메서드는 as~
    • asList
  • 객체의 값을 기본 타입으로 반환하는 메서드는 ~Value
    • intValue
  • 정적 팩터리라면 from, of, valueOf, newInstance, getType ... 등을 흔히 사용한다.

필드

  • 규칙이 덜 명확하고 덜 중요하다.
  • boolean 타입의 필드명은 보통 boolean 접근자 메서드에서 앞 단어를 뺀 형태이다.
    • initialized, composite
  • 다른 타입의 필드는 명사, 명사구를 사용한다.
    • birth, planType
  • 지역변수 명은 비슷하지만 조금 더 느슨하다.

😎 정리

  • 표준 명명 규칙을 잘 익히고 자연스럽게 사용할 수 있게 연습하자
  • 철자 규칙은 직관적이지만, 문법 규칙은 더 복잡하고 느슨하다
  • 오랫동안 따라온 규칙과 충돌한다면 그 규칙을 맹종해서는 안된다. 상식대로 가자

👀 더 읽어볼거리

메서드 이름

빌더와 조정자의 차이를 생각하고 지으면 더 좋은 이름이 나타날 수 있다.

Untitled

엘레강트 오브젝트

// 잘못된 예시들
int save(String content); // 새로운 객체를 반환하는 메서드(빌더)지만 동사로 지어져있음(조정자)
void speed(String value); // 객체를 수정하는 메서드(조정자)지만 명사로 지어져있음(빌더)

좋은 객체의 7가지 덕목

번역본 / 원문

→ 읽으면서 일반적으로 서술하는 '객체'와 충돌되는 개념이 몇가지 있을 수도 있습니다. 자신이 맞다고 생각하는 개념과 근거에 따라 객체를 설계하는 것이 좋다고 생각합니다.

  • 객체는 현실 세계에 존재하며, 객체는 생명체로 취급해야한다.
    • 그렇기 때문에 컨트롤러, 파서, 필터등은 좋은 객체가 아니다. → 이것 들은 현실세계에 존재하지 않기 때문이다. → 즉, 대부분은 GoF 패턴은 안티패턴이다(!!)
  • 객체가 살아있는 동안은 변하지 않은 채로 머물러야한다. (불변적이여한다.)
  • 객체의 클래스에는 정적 멤버가 없다.
  • 객체의 이름에서 객체가 하는 역할을 드러내면 안된다. (ex. FileReader)
  • 등등 ...

위 의견을 제시한 이유가 궁금하다면?

지금 당장 읽어보세요! 😉