객체지향 9가지 규칙
규칙 1. 한 메서드에 오직 한 단계의 들여 쓰기만 한다.
규칙 2. else 예약어를 쓰지 않는다.
규칙 3. 모든 원시 값과 문자열을 포장한다.
규칙 4. 한 줄에 점을 하나만 찍는다.
규칙 5. 줄여 쓰지 않는다.(축약 금지)
규칙 6. 모든 엔티티를 작게 유지한다.
규칙 7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8. 일급 컬렉션을 쓴다.
규칙 9. 게터/세터/프로퍼티를 쓰지 않는다.
규칙 1. 한 메서드에 오직 한 단계의 들여 쓰기
- 한 메서드 길이는 5줄로 제한하기
- 한 메서드당 하나의 제어 구조 or 문장 단락(block)
규칙 2. else 예약어 금지
- 지저분한 코드가 되기 쉽다
- 조건문은 중복의 원흉
- Strategy 패턴은 상태에 대한 분기가 몇 군데 걸쳐 중복 되어 있을 때 유용
- 객체 지향 언어는 다형성이라는 강력한 도구를 통해 복잡한 조건문을 처리할 수 있다
- 간단한 경우라면 보호절(guard clause)와 조기 반환(early return)으로 대체 가능
- 다형성을 채택한 설계는 읽고 유지하기 쉬우며 분명한 코드의 의도를 표현
- 널 객체 패턴(Null Object Pattern)을 시도하면 특정 상황에서 도움이 될 것
규칙 3. 원시 값과 문자열의 포장
- 어떤 메소드가 int 값을 매개 변수로 받는다면, 그 메서드 이름은 해당 매개 변수의 의도를 나타내기 위해 수단과 방법을 가리지 말자
- 원시형 변수로는 컴파일러가 의미적으로 맞는 프로그램 작성을 안내할 수 없다.
규칙 4. 한 줄에 한 점만 사용
- 코드 한 줄에서라도 점이 하나 이상 있으면, 그 곳에서 다른 동작이 일어나고 있다는 뜻
- 그 모든 점들이 연결되어 있다면, 대상 객체는 다른 객체에 깊숙이 관여하고 있다는 뜻이고, 이러한 중복된 점들은 캡슐화를 어기고 있다는 뜻이다.
- 캡슐화의 주 요점은 클래스 경계를 벗어나 알 필요가 없는 타입으로 진입하지 않는 것.
규칙 5. 축약 금지
- 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다.
- 클래스와 메서드 이름을 한두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제한다.
ex) 클래스 이름이 Order라면 메서드 이름은 ship()이라고 네이밍 한다.
규칙 6. 모든 엔티티를 작게 유지
- 50줄 이상 되는 클래스 파일이 10개 이상인 패키지는 없어야 한다.
- 50줄 이상의 클래스는 보통 한 가지 일 이상을 하는 것이며, 따라서 코드의 이해와 재사용을 어렵게 한다.
- 50줄 이하의 클래스는 스크롤 하지 않고도 한 화면에 볼 수 있다는 부가적인 혜택도 있으며 한눈에 파악하기 쉽다.
- 클래스가 점점 작아지고 하는 일이 줄어들며 패키지 크기를 제한함에 따라 패키지가 하나의 목적을 달성하기 위해 모인 연관 클래스들의 집합을 나타낸다.
- 패키지도 클래스처럼 응집력 있고 단일한 목표가 있어야 한다.
- 패키지를 작게 유지하면 패키지 자체가 진정한 정체성을 지니게 된다.
규칙 7. 3개 이상의 인스턴스 변수를 가진 클래스 사용 금지
- 대부분의 클래스가 간단하게 하나의 상태 변수를 처리하는 일을 맡아 마땅하지만 몇몇 경우 둘을 필요할 때가 있다.
- 새로운 인스턴스 변수를 하나 더 기존 클래스에 추가하면 클래스의 응집도는 즉시 떨어진다.
규칙 8. 일급 콜렉션 사용
- 콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 한다.
- 각 콜렉션은 그 자체로 포장 되어 있으므로 콜렉션과 관련된 동작은 근거지가 마련된 셈.
규칙 9. 게터/세터/속성 사용 금지
- 만약 객체가 지금 인스턴스 변수의 적당한 집합을 캡슐화 하고 있지만 그 설계가 여전히 어색하다면, 좀 더 직접적인 캡슐화 위반을 조사한다.
- 강한 캡슐화 경계의 바탕에 깔린 사상은 동작의 검색과 배치를 위해 남겨둔 코드를 만질 다른 프로그래머를 위해 객체 모델의 단일한 지점으로 유도하려는 것이다.
- 이는 많은 긍정적인 하부 효과를 가져다 주는데, 중복 오류의 극적 축소와 새 기능의 구현을 위한 변경의 지역화 개선 등이 있다.