켄트백의 구현 패턴 5장 - 클래스(1)

클래스

클래스는 비슷한 성질을 가진 것을 총칭하며, 객체는 클래스가 구체화된 것이다.

 

클래스

 

클래스의 로직과 데이터는 함꼐 사용되며, 로직은 데이터에 비해 변화율이 낮다. 클래스 내부의 데이터는 
관련 로직에 의해 변화하며, 클래스 내부에서 사용하는 데이터의 변화율은 비슷하다.

대체로 이 선언을 내포하기는 하지만 절대적이지는 않다.

 

따라서 효과적인 프로그래밍을 위해서 로직을 클래스 단위로 어떻게 구성해야 하난지, 로직 사이의 차이점을 어떻게 효과적으로 

표현해야하는지 배워야 한다.

 

클래스 계층을 사용하면 하위 클래스를 이해하기 위해 상위 클래스 또한 모두 이해해야 하므로 읽기 어려워진다.

모든 클래스를 상속받기 보단 선별적으로 클래스를 상속하자

 

클래스는 프로그램의 설계 요소 중 값이 비싼 편이므로, 의미 있는 작업에만 클래스를 사용해야한다.

다른 클래스의 크기를 유지하면서 클래스의 수를 줄이는 것이 프로그램을 개선한 것이라고 볼 수 있다.

 

단순한 상위 클래스 이름

 

적합한 클래스 이름은 코드를 단순화하고 향상 시켜준다.

중요한 클래스 이름에 대해서는 한 단어로 된 이름을 사용하고 , 메타포(은유)를 사용하면 좋다 !

 

한정적 하위클래스 이름

 

하위클래스 이름은 상위 클래스와 달리 간결성은 포기하더라도 표현성을 택하는 것이 좋다.

하지만 그 하위클래스가 다른 클래스의 상위 클래스라면 다시 단순성을 선택해야한다.

 

다른 경우는 다단계 클래스 계층이다. 

기계적으로 바로 위의 상위 클래스 이름에 수식어를 붙이기 보단 , 가장 유사한 상위 클래스의 이름을 바탕으로

짓는 것이 좋다.

 

효과적인 커뮤니케이션을 위해 좋은 클래스 이름이 필요하다.

이름에 연관성이 없는 클래스는 이해하기도 기억하기도 어렵다.

클래스 이름은 코드의 내용을 반영해야한다.

 

추상 인터페이스

 

설계상의 결정을 필요 이상으로 노출하지 않아야한다.

 

인터페이스란 구현이 빠진 여러 연산의 집합을 의미한다.

하지만 인터페이스 추가에는 비용이 발생한다.

따라서 유연성을 얻을 수 있는 경우에만 추가 설계에 대한 비용을 지불해야한다.

실제로 유연성이 필요하지 않는 경우도 매우 많다.

 

저번 장에도 말했듯이 불확실한 미래를 예측하기 보단 당장의 이익을 취하자

추후 필요해지는 경우에만 시스템에 유연성을 부여하는 편이 바람직하다.

 

인터페이스

 

자바 인터페이스를 사용하는 것은 "여기까지가 내가 원하는 것이고 , 이외의 내용은 상관하지 않는다."

라는 내용을 내포한다.

인터페이스는 필드를 배제하고 연산만을 나타내므로 사용자는 구현이 변경되더라도 신경 쓸 필요가 없다.

 

반대로 구현을 바꾸는 것은 쉽지만 인터페이스 자체를 변경하는 것은 쉽지 않다.

변경 시에 모든 구현 클래스를 수정해야하기 때문이다.

 

버전 인터페이스

 

만약 인터페이스를 바꾸고 싶은데 설계를 수정하는 것이 부담스러운 경우, 버전 인터페이스를 사용할 수 있다.

이렇게 하면 기존 인터페이스를 생속헤서 새로운 연산을 추가하므로 사용자는 기존 인터페이스에 대해 알 필요가 없다.

 

하지만 버전 인터페이스는 그리 좋은 방법이 아니다.

버전 인터페이스가 늘어날 수록 결국 관리해야할 로직,클래스가 많아지므로 클라이언트가 할 일이 늘어난다.

이는 설계 자체를 수정할 때가 되었다는 것이다.

 

추상 클래스

 

추상 인터페이스를 구현하는 또 다른 방법은 추상 클래스를 사용하는 것이다.

 

인터페이스와 비교했을 때 장단점이 있다.

 

먼저 수정의 관점에서 보면 추상 클래스는 수정에 용이하다.

기존 설계를 유지하면서 얼마든지 새로운 연산을 추가할 수 있다.

 

하지만 추상 클래스는 단 1개의 상위 클래스만을 지정할 수 있다.

이는 여러 개의 인터페이스를 구현할 수 있는 것과 대조된다.

 

자바 클래스에서 abstract 키워드를 씀으로써, 해당 클래스를 사용하기 위해서는

반드시 구현이 필요하다는 사실을 전달할 수 있다.

 

 

값 객체

 

함수형(값) 스타일 연산은 상태를 변화시키지 않으며 새로운 값을 생성한다.

고정적인 상황을 표현하고 함수형 스타일이 적절하고 , 상황이 변하는 경우라면 상태를 사용하는 편이 낫다.

 

값 스타일 객체의 문제점은 성능이다.  (하지만 매우 미비하다)

다른 문제는 값 스타일과 상태로 부분을 구별하기 쉽지 않다는 것이다.

 

따라서 두 스타일을 적절히 섞어서 사용하는 것이 좋다.

 

특화

 

연산 간의 유사점과 차이점을 부각시키는 방향으로 코드를 작성하면 , 프로그램을 읽고 수정하기 쉬워진다.

이런 방식을 사용하면 명확히 코드를 이해하고 새로운 요구 사항을 처리할 수 있을 지를 알 수 있다.

또한 수정이 필요한 경우 기존 코드를 변형할지 새로 만들지를 판단할 수 있다.

 

대부분의 프로그래밍은 두 가지의 극단적 변형 사이에 존재한다.

현실에서는 약간 변형된 입력 데이터를 시용하거나 약간 변형된 로직을 사용하는 경우가 많다.

 

하위 클래스

 

제대로 된 상위클래스를 가지고 있다면 하위 클래스는 강력한 힘을 발휘할 수 있다.

 

하지만 하위 클래스의 사용은 여러 문제를 야기한다.

1. 하위 클래스의 사용을 되돌리기 어렵다.

2. 하위클래스를 이해하기 위해 상위 클래스까지 이해해야한다. 

3. 상위 클래스의 수정이 조심스러워진다.

 

이러한 문제점을 잘 알고 있다면 하위 클래스는 강력한 도구가 될 수 있다.

상위 클래스의 로직을 여러 개의 메소드로 잘게 쪼개면 각 메소드를 따로 오버라이드 할 수 있다.

 

하위 클래스는 동적으로 변화하는 로직을 나타낼 수 없다.

따라서 이 경우네는 조건문이나 위임을 사용하는 것이 바람직하다. 

 

구현자

 

객체지향 프로그램에서는 다형적 메시지를 통해 선택을 표현할 수 있다.

덕분에 연산의 내부 구현에 대해서는 신경 쓰지 않아도 된다.

 

다형적 메세지는 여러 가지 변경을 수용할 수 있다.

프로그램이 다른 시스템에 일련의 데이터를 전송하는 경우, 추상 클래스를 사용하면 호출 코드에 영향을 주지 않고

구현을 자유롭게 바꿀 수 있다.

 

이는 효과적으로 프로그래머의 의도와 구현을 분리할 수 있다.

또한 상상하지 못했던 미래의 확장을 수용할 수 있다.