다른 하위 클래스로 변환하기위한 하위 클래스 만들기

Question

방금 ​​가입 한 새 회사의 코드베이스를 살펴볼 때 생각했던 적이 없었던 것을 발견했습니다. 기본적으로 이런 일이 발생합니다. 여러 이미지 유형간에 변환 할 수있는 몇 가지 추상 메소드가있는 이미지를 나타내는 기본 클래스가 있습니다. 다른 이미지 유형은 기본 Image 클래스의 서브 클래스입니다. 서브 클래스는 모든 파생 클래스 인 다른 이미지간에 변환을 담당합니다.

제 질문은 이것이 좋은 디자인으로되어있는 것입니까? 만약 우리가 대안을 가질 수 없다면?

고마워요. 내가 시나리오를 설계하는 경우

Answer 1

는 전 단지를 대표 줘야 추상적 인 방법으로

1. 기본 클래스 이미지 (내 개념을 공유하는 나는, 아주 좋은 디자이너가 아니다 NB) 다음 .. 할 것 behavior 변환 할 액션이 아님
2. 행동을 정의하는 추상 클래스를 구현하는 서브 클래스
3. 다른 이미지간에 변환하는 메소드가있는 다른 유틸리티 클래스.

Answer 2

가장 세련된 구조는 아니지만 작동 할 수있는 이미지 유형은 몇 가지입니다. 변환을 공통 기본 클래스의 일반 기능으로 변경하면 이미지 유형이 더 풍부 해지고 확장 성이 향상됩니다. 단점은 변경 사항을 도입하고 자체 디자인 트레이드 오프를 수행한다는 것입니다.

아키텍처의 주요 질문은 다음과 같습니다

1. 어디? 타입 X를 타입 Y로 변환하는 방법에 대한 지식은 어디에 두어야합니까? X 형 내부? 내부 형 Y? 공통의 조상 안쪽에? 또는 일부 별도의 전환 시설 내에서?
2. 어떻게? X가 Y로 직접 내보내는 방법을 알고 있어야합니까? 또는 X는 X에서 가져 오는 방법을 알고 있어야합니까? 또는 X가 generic/common 형식으로 내 보내야합니까? 그러면 Y가 가져 오는 방법을 알고 있습니까?

이러한 옵션은 모두 야생에서 찾을 수 있습니다.

각 이미지 클래스 내에서 변환 된 현재 디자인은 여러 언어로 된 매우 기본적인 데이터 유형/클래스를 반영합니다. 그들은 각각 일련의 다른 형식 (예 : 문자열, 피클과 같은 over-the-wire 형식 등)으로 일련 화, 표현 또는 변환 할 수 있어야합니다. 그러나 몇 가지 유형 이상인 경우 X 축 대 Y 축 변환기에서 작성하면 quickly grow unmanageable이됩니다. n (n-1) 개의 변환 방법이 필요합니다. "아무도 시간이 없어!"

반면에 netpbm 및 pandoc과 같은 변환 및 조작 도구는 흔히 일반 중간 표현을 사용합니다. 자신의 상황을 알고있는 가장 가까운 아날로그 이미지 라이브러리 Python's PIL/Pillow은 흔히 디스크 기반 형식이 아닌 경우에도 일반 형식/데이터 모델의 역할을 수행하는 일반 기본 클래스 (예 : Image)를 정의합니다. .

추상화는 항상 불완전합니다. X 또는 Y 만 처리하면 상속이 멋지게됩니다. 그러나 X 유형의 복잡성을 처리하고 Y 을 동시에 입력해야하는 경우에는이라는 완벽한 대답은 없습니다.추가 수업으로 분해하면 도움이되지 않습니다. 다중 상속도 마찬가지입니다.

패러다임과 아마도 가장 좋은 대답은 변환을 기본 클래스로 옮기는 것입니다. 그러나 이것은 자신의 절충안이 아닙니다. 그런 다음 기본 클래스는 모든 가능한 하위 클래스에 대한 변환을 파악하고 수용해야합니다. 따라서 알파 채널, CLUT, Z 버퍼, 감마 보정 테이블, HDR 교정 정보 및 기타 데이터/메타 데이터가없는 형식을 변환하는 경우에도 기본 클래스 방법 및 데이터 구조는 그러한 것들을 가진 경우 의 하위 클래스에 그러한 것들이 있습니다. 푸시 컨버전 업 스택은 기본 메소드가 서브 클래스를 조사하거나 태스크를 위임하려고 할 때 기본 클래스와 하위 클래스 (설계와 런타임 모두) 간의 탁구 대화로 이어질 수 있습니다. 그러나 주택 개조에 대한 이러한 우려는 2 차적인 문제입니다. 당신이 실제로 그들을 만나지 않는 한, 그들은 너무 짜증납니다.

순수한 조언은 다음과 같습니다. 몇 가지 이미지 유형의 경우 이미지 유형별로 변환이 합리적으로 이루어집니다. 이것은 이미 "접근하고있는 새"- 이미이 접근법을 취하는 작동하고 테스트 된 코드가있는 경우에 특히 그렇습니다. 그러나 디자인을 "정리"하려면 가져 오기/내보내기/변환을 기본 클래스로 이동하는 것이 추가 이미지 유형보다 우아하고 확장 성이 좋습니다. (행진을 시작하기 전에 기존 구현에 대한 단원 테스트를 통해 2 세대 코드를 쉽게 검증 할 수 있도록하십시오.)