객체지향생활체조

[출처] http://elaia.tistory.com/3 

 

 

- 훈련규칙

1. 한 메소드에 오직 한 단계의 들여쓰기만 한다.
2. else 예약어를 쓰지 않는다.
3. 모든 원시값과 문자열을 포장한다.
4. 한 줄에 점을 하나만 찍는다.
5. 줄여쓰지 않는다.
6. 모든 엔티티를 작게 유지한다.
7. 2개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
8. 제일 클래스(first-class)  콜렉션을 쓴다.
9. getter/setter/property를 쓰지 않는다.

 

- 설명

규칙1 : 메소드당 들여쓰기 한번

객체지향 기본 원칙 중 하나는 느슨한 결합, 강한 응집력입니다.

하지만 덩치가 큰 메소드는 정확한 하나의 일에 집중되어 있지 않기에 응집력이 떨어지며,

나중에는 재사용 하기도 어려워 집니다.

즉 정확한 하나의 일(하나의 제어구조나 하나의 문장 단락)에만 집중할 수 있도록 구현하라는 뜻입니다.

 

규칙2 : else 예약어를 쓰지 않는다.

거의 모든 프로그래머들은  따라가기 불가능할 정도로 지저분한 중첩 조건문이나, 많은 양의 case문을 본적이 있을 겁니다.

더욱이 리팩토링보다 그냥 조건문에 분기 하나 더치기가 훨씬 쉽다는 점 때문에 조건문은 나쁜 복제의 원흉이 되기도 합니다.

여기서는 else 예약어를 대신 할 2가지 대안에 대해서 말합니다.

첫째, 다형성을 이용하여 복잡한 조건문을 처리 (패턴에서는 Strategy 패턴이 이 케이스에 속하죠.)

둘째, 간단한 경우라면, 보호절과 조기 반환(early return)으로 대신

위와 같이 한다면 복잡한 케이스문을 사용하는 것보다 훨씬 간결하고 이해하기 쉬운 코드를 생성할 수 있습니다.

 

규칙3 : 원시값과 문자열의 포장

원시형 변수로는 컴파일러가 의미적으로 맞는 프로그램 작성을 안내할 수 없습니다.

오브젝트로라면 아주 사소하더라도 컴파일러와 프로그래머에게 그 값이 어떤 값이며 왜 쓰이고 있는지에 대한 정보를 전할 수 있습니다.

 

규칙4 : 한 줄에 한 점만 사용

디미터법칙(Demeter) : 친구하고만 대화하라.

참조에 참조를 사용한다는 것은 느슨한 결합을 훼방하는 주요원인입니다.

 

규칙5 : 축약금지

누구나 클래스, 메소드, 또는 변수의 이름을 줄이려는 유혹에 빠지곤 합니다.

하지만 그런 유혹을 물리쳐라!

메소드의 이름을 잘 지으면 쓸데없는 주석도 필요없게 됩니다. [잘 지어진 하나의 이름 열 주석 부럽지 않습니다.;)]

ex) 클래스 이름이 Order라면 메소드 이름을 shipOrder라고 할 필요 없이, order.ship() 이라는 식으로 사용하는 것이 더 직관적입니다.

 

규칙6 : 모든 엔티티를 작게 유지

클래스가 점점 작아지며 하는 일이 줄어들며 패키지 크기를 제한함에 따라

패키지가 하나의 목적을 달성하기 위해 모인 연관 클래스들의 집합이 되어가는 것을 알 수 있습니다.

패키지도 클래스처럼 응집력 있고 단일한 목표가 있어야 합니다.

 

규칙7 :  2개 이상의 인스턴스 변수를 가진 클래스 사용 금지

대부분의 클래스들이 간단하게 하나의 상태 변수를 처리하는 일을 맡아 마땅하지만, 몇몇 경우 둘이 필요할 때가 있습니다.

하지만 새로운 인스턴스 변수를 하나 더 추가하게 되면 클래스의 응집도는 떨어집니다.

유지하고 처리해야 하는 변수가 하나 더 늘기에

 

규칙8 : 일급 콜렉션 사용

이 규칙의 적용은 간단합니다. 콜렉션을 포함한 클래스는 반드시 다른 멤버 변수가 없어야 합니다.

각 콜렉션은 그 자체로 포장이 되어 있으므로 이제 콜렉션과 관련된 동작은 근거지가 마련된 셈입니다.

사실 이 부분은 잘 이해가 안가는데, 문맥적으로만 저자의 말을 이해하자면, 콜렉션은 매우 강력하고 유용한 원시데이터 형태이며, 이 것을 포함한 클래스는 다른 멤버변수 없이 해당 콜렉션을 처리하는 함수들로만 구현되어야 한다는 것입니다.

결국 해당 클래스는 콜렉션의 필터로서만의 역할을 해야한다는 것이죠.

(하지만 제가 느끼기에 다른 멤버변수가 있다고 해도 이 역할을 흐리지 않을거 같은데, 정확한 의미는 제가 이해되는 시점에 다시 작성하겠습니다.)

 

규칙9 : getter/setter/property를 쓰지 않는다

만약 오브젝트가 지금 인스턴스 변수의 적당한 집합을 캡슐화하고 있지만 그 설계는 여전히 어색하다면,

좀 더 직접적인 캡슐화 위반을 조사해 볼 때입니다. 그냥 단순히 현재 위치에서의 값을 물을 수 있는 동작이라면

해당 인스턴스 변수를 제대로 따라가지 못 할 것입니다. 강한 캡슐화 경계의 바탕에 깔린 사상은 동작의 검색과

배치를 위해 남겨둔 코드를 만질 다른 프로그래머를 오브젝트 모델의 단일한 지점으로 유도하려는 것입니다.

이는 많은 긍정적인 하부 효과를 가져다주는데, 중복 오류의 극적 축소와 새 기능의 구현을 위한 변경의 지역화

개선이 있습니다.