오브젝트 지향의 특징으로서 자주 나오는 계승이라는 구조.
편리하지만, 상태를 타고 사용하면 아픈 눈을 볼 수 있습니다.

상속의 예

알기 쉬운 예로는 게임 캐릭터로 표현하면 알기 쉽습니다.

· 캐릭터는 이름과 HP와 MP를 가지고 있습니다. 또한 복구하는 방법이 있습니다.
・히어로는 필살기 횟수를 가지고 있습니다.
· 적은 경험치와 돈을 가지고 있습니다.

캐릭터

class Character {
  string name;
  int hp;
  int maxHp; // 最大HP
  int mp;
  int maxMp; // 最大MP

  // 回復する
  recoveryHp( value ) {
    int hp = this.hp + value;
    if( maxHp < hp){
      this.hp = maxHp;
    }else{
      this.hp = hp;
    }
  }
}

영웅

class Hero extends Character {
  int skillCount;
}

적

class Enemy extends Character {
  int exp; // 経験値
  int money;
}

Hero와 Enemy는 Character를 상속합니다.
이렇게하면 Hero와 Enemy 모두 이름과 hp 및 mp 메커니즘을 모두 가질 수 있습니다.
또한 recoveryHp도 사용할 수 있습니다.

hero = new Hero();
hero.name; // 使える
hero.hp; // これも使える

이렇게 하면, Character 자체에 power(공격력)가 늘어나는 등, 추가 요소가 있어도 상속원의 Character 클래스를 고치는 것만으로,
Hero 및 Enemy에 기능을 추가할 수 있습니다.

기능을 늘리자

예를 들어 캐릭터의 얼굴 아이콘인 썸네일 이미지를 반환하는 메커니즘이 필요하다고 가정합니다.

class character {
  // 
  // 既存の処理
  //
  string iconUrl;

  createThumbnail() {
    binary = download(character.iconUrl);
    image = Image.create(binary);
    return image;
  }
}

이와 같이 처리를 늘리면, 썸네일 화상을 취득하는 메소드를 만들 수 있습니다.
hero 혹은 enemy 에서도 호출하는 것만으로, 썸네일 화상을 취득할 수 있습니다.



죄송합니다. . .

점차 점점 더 향상되고 있습니다 ...

그런데 다음에 일어나는 일로, Character에 점점 기능이 늘어나는 것입니다.
예를 들어 power라는 힘의 항목이 늘어나거나 방어력이 늘어나거나 필요한 항목이 점점 늘어납니다.
방법에서도 독 상태가 되어 HP가 줄어든다. 캐릭터 음성을 재생하는 기능도 늘어날지도 모릅니다.

이것을 대응해 나가면, 점차 Character 에 메소드가 점점 늘어나고 있어,
1000행을 넘게 됩니다.

그리고 신 클래스에 ...

하나님이라 불리는 클래스가 되어, 취급하기 어려워져, 술자리에서의 암캐로 연결되어 가거나 합니다.
이런 게 좋지 않아요・・・.

그럼 어떻게 할까

분할합니다.

이전 예에서 나타낸 썸네일 작성의 처리는 나누어지기도 합니다.
다음과 같은 클래스를 만듭니다.

class ThumbnailCreator {
  static createCharacter(charcter) {
    binary = download(character.iconUrl);
    image = Image.create(binary);
    return image;
  }

  static createItem(item) {
    binary = download(character.iconUrl);
    image = Image.create(binary);
    return image;
  }
}

썸네일을 만드는 과정은 ThumbnailCreator로 나눌 수 있었습니다.
이제 Character에서 처리를 생략할 수 있었습니다.
또, ThumbnailCreator 에는, Item 의 썸네일 작성 처리 등,
썸네일 작성계는 전부 넣거나 할 수 있습니다.
썸네일 작성을 위한 공통적인 처리도 여기에 넣어 둘 수 있습니다.

원래의 Character 에는, 이하의 처리만 넣어 두어도 됩니다.

class Character {
  createThumbnail() {
    return ThumbnailCreator.createCharacter(this);
  }
}

이렇게 하면 처리를 다른 클래스로 이동하면서 호출 방법도 변하지 않는 이상적인 상태가 가능합니다.

마찬가지로 음성 재생 처리도 voiceManager 등의 클래스를 만들어 분할해 나갈 수 있습니다.

완성의 이미지는 이런 느낌입니다.



이렇게 1클래스를 너무 뚱뚱하게 하지 않도록 하나님이 되지 않을 클래스로 하고,
적절하게 처리를 분할하는 것이 설계에 중요합니다.

요약

우선 먼저 개발하고 나중에 리팩토링

대신,

리팩토링과 신규 개발을 50:50 등 항상 힘을 배분해 둔다

그렇게 함으로써 제품을 고품질로 유지할 수 있습니다.