개체지향 - 상속 계층 구조의 확장을 용이하게 하는 제안 사항

 

 

클래스 계층 구조의 확장을 용이하게 하는 제안 사항

 

상속 계층 구조는 디장니하는 것보다 구현하기가 더 쉬우므로 요구 사항을 명확히 정의하고 난 다음 코딩을 시작해야 문제가 없다. 구현이 끝난 후에 클래스 계층 구조에 발생한 디자인 오류를 수정하려는 경우, 코드를 변경해야 하며 기존 응용 프로그램을 사용할 수 없게 되는 경우가 있다.

 

또한 잘 디자인된 클래스 계층 구조의 경우에도 지속적인 향상은 필요하다. 클래스 계층 구조를 다지인할 때 어떤 방식을 선택하느냐에 따라 나중 작업이 간단해질 수 있다. 다음은 클래스 계층 구조의 확장을 용이하게 하는 제안 사항이다.

 

1. 일반적인 것에서 구체적인 것으로 정의한다. 상속 계층 구조의 각 수준에서 가능한 일반적인 것으로 클래스를 정의한다. 파생 클래스는 기본 클래스의 메서드를 상속하고 다시 사용하고 확장할 수 있다.

 

2. 데이터 형식 및 저장소를 정의할 때 되도록이면 포괄적으로 정의하여 나중에 변경할 필요를 없애 준다. 예를 들어, 현재 데이터에 표준 Integer 변수만 필요한 경우에도 Long 형식의 변수를 사용할 수 있다.

 

3. 파생 클래스에 필요한 항목만 노출한다. Private 필드 및 메서드는 이름 충돌을 줄여 주며 나중에 변경해야 하는 항목을 다른 사용자가 사용하지 못하도록 한다.

 

4. 파생 클래스에만 필요한 멤버는 Protected로 표시해야 한다. 이렇게 하면 파생 클래스만 해당 멤버에 종속되며 개발 중에 해당 멤버를 보다 쉽게 업데이트할 수 있다.

 

5. 기본 클래스 메서드가 상속하는 클래스에 의해 기능이 변경될 수 있는 Overridable 멤버에 종속되지 않는지 확인한다.

 

 

 

 

클래스의 멤버의 최적의 액세스 수준

 

이와 함께 클래스 계층 구조의 멤버에 최적의 액세스 수준을 적용하면 이러한 멤버가 사용되는 방식을 제어할 수 있으므로 계층 구조를 보다 쉽게 유지 관리할 수 있다. 일반적으로 최소의 액세스 권한을 제공하는 액세스 한정자로 클래스 멤버를 선언해야 한다. 클래스 멤버에 대한 액세스를 제한하면 이름 충돌이 줄어 들어 메서드가 원하지 않는 방식으로 사용되지 않도록 할 수 있다.

 

내부 클래스 멤버는 Private로 선언되어야 한다. 즉, 이러한 멤버는 해당 멤버가 선언된 클래스 내에서만 액세스할 수 있다.

 

클래스 내에서 또는 클래스의 하위 항목에 의해서만 사용되는 메서드는 Protected 액세스 한정자를 사용해야 한다. Protected 멤버는 해당 멤버가 선언된 클래스 내에서 또는 해당 멤버를 선언한 클래스에서 파생된 클래스 내에서 액세스할 수 있다.

 

Friend 데이터 멤버는 클래스 외부에서 액세스 할 수 있지만 해당 클래스가 정의된 프로젝트에 속하는 모듈에서만 액세스할 수 있다.

 

Public 데이터 멤버는 모든 사용자가 볼 수 있으며 주로 클래스 계층 구조 맨 아래에서 사용된다.

 

 

 

의도하지 않던 디자인 변경 사항이 발생했을 때

 

클래스 계층 구조를 약간만 변경해도 의도하지 않던 결과가 발생할 수 있으므로 클래스 계층 구조를 배포한 후에는 변경하지 않는 것이 좋다. 그러나 실제로는 이러한 변경이 불가피할 때도 있다. 즉, 제품 요구 사항이 달라질 수 있으며 다지인 사양에 핵심 요소가 빠지는 경우도 있다. 상속 문제의 여러 범주 중 하나가 손상되기 쉬운 기본 클래스 문제이다.

 

상속 계층 구조를 사용할 때 나타나는 주요 문제점은 손상되기 쉬운 기본 클래스 문제이다. 기본 클래스를 변경하면 경우에 따라 기본 클래스 및 파생 클래스의 모든 코드를 변경하고, 다시 컴파일하고, 다시 배포해야 한다. 이러한 문제점은 여러 개발자가 기본 클래스 및 파생 클래스를 작성할 때 더욱 두드러진다. 왜냐하면 각 개발자가 자신의 소스 코드에 대한 액세스를 거부할 수 있기 때문이다. 최악의 경우, 고객의 실수로 파생 클래스의 원본 및 호환되지 않는 이진 버번과 업데이트된 기본 클래스의 컴파일된 이진 형식을 함께 사용할 수도 있다.

 

파생 클래스를 손상시킬 수 있는 기본 클래스 변경 작업에는 기본 클래스 멤버의 데이터 형식을 재정의하거나 변경하는 경우가 포함된다.

 

손상되기 쉬운 기본 클래스 문제를 피하는 가장 좋은 방법은 파생 클래스만 변경하는 것이다. 그러나 기본 클래스가 먼저 릴리즈될 경우에는 모든 가능성을 고려해야 하므로 이와 같이 파생 클래스만 변경하는 방법이 항상 가능한 것은 아니다. 불가피하게 기본 클래스를 갑자기 변경해야 하는 경우도 발생할 수 있기 때문이다.

 

MustInherit 클래스와 MustOverride 메서드를 사용하면 구현 세부 사항이 파생 클래스로 이동하게 되고 기본 클래스를 변경해야 할 필요가 줄어들기 때문에 손상되기 쉬운 기본 클래스 문제를 줄이는 데 도움이 된다. 그러나 완벽하게 계획된 경우라 할지라도 항상 이렇게 할 수 있는 것은 아니다.

 

파생 클래스에 숨겨진 데이터 멤버도 기본 클래스 멤버와의 이름 충돌을 줄여 주므로 도움이 된다.

 

기본 클래스의 기능을 확장하는 가장 안전한 방법은 새 멤버를 추가하는 것이다. 새로운 멤버로 인해 기본 클래스가 손상될 수 있는 유일한 경우는 파생 클래스가 Overloads 키워드를 사용하여 기본 클래스에서 메서드를 상속하고 같은 이름의 새 메서드를 추가하는 경우이다. 기본 클래스에서 상속하려는 기본 클래스 메서드를 파생 클래스에서 명시적으로 지정한 다음 해당 클래스에 위임하면 이러한 문제를 피할 수 있다.

 

모든 기본 클래스는 어느 정도 손상될 가능성이 있다. 그러므로 손상되기 쉬운 기본 클래스 문제를 제거할 수는 없지만 기본 클래스를 변경할 필요를 줄이도록 클래스 계층 구조를 신중하게 디자인하고 이러한 변경이 불가피할 경우에는 철저한 테스트를 수행하여 문제를 최소화할 수 있다.