6.1 조건 분기 중첩 → 가독성 떡락

• 조건문을 중첩하면
  • 가독성 떡락
  • 사양 변경 어렵
• early return으로 중첩 제거
  • 간단하게 기능추가 가능
  • 가드도 early Return 중 하나
  • 요구사항을 그대로 구현한 형태가 가능해짐
• else 구문 지양
  • 조기 리턴 사용하면 제거 가능

6.2 switch 조건문 중복

• switch 문은 악마 콜렉터
  • 대게 비슷한 형태의 switch문이 중복되는 경향 있음
  • 요구사항 변경 시 Case 구문 추가 누락 가능성 높음
• SRP
  • 비슷한 형태의 switch문을 한 군데(클래스) 모아서 관리하는 방법
• 인터페이스
  • SRP로 만들어진 클래스가 너무 커지면 나눠야 함
  • 분기로직 작성 않고도, 분기 기능 구현 가능
  • 구현 강제
  • implements : is able to
  • extends : is a kind of
• 전략패턴

  • 다른 로직을 같은 방식으로 처리 가능

  • 다르게 처리하고 싶은 로직을 인터페이스의 메소드로 정의

  • 조건분기 없이 분기처리 가능

    final Map<MagicType, Magic> magics = new HashMap<>();
    
    void magicAttack(final MagicType magicType) {
    		final Magic usingMagic = magics.get(magicType);
    		
    		showMagicName(usingMagic);
    		consumeMagicPoint(usingMagic);
    		consumeTechnicalPoint(usingMagic);
    		magicDamage(usingMagic);
    }

6.3 조건 분기 중복과 중첩

• 정책 패턴
  • 조건 = 부품
  • 정책 = 조건 조합 = 부품 조합

6.4 자료형 확인에 조건 분기 금지

• instanceof 키워드 사용하지 말라는 뜻
• 사용하면 일단 LSP가 깨짐
  • 기반자료형 = 인터페이스
  • 하위자료형 = 구현 클래스
  • 기반자료형을 하위자료형으로 변경해도 문제 없어야 함
  • 이게 깨졌기 때문에 instanceof 가 필요한 거기 때문

6.5 인터페이스 사용 능력이 중급 레벨업 첫 단계

• 조건 분기를 써야하는 상황에서는 일단 인터페이스 설계를 떠올리자!!

6.6 플래그 매개변수

• boolean, int 매개변수를 통해 메소드 내 기능을 분기처리하는 변수
• 암튼 쓰면 안 됨
  • 예측 어려움
  • 가독성 떡락
  • 개발 생산성 떡락
• 메소드 역할이 무겁기 때문
  • 메소드 당 하나씩 역할 SRP를 만족시켜주면 해소됨

interface Damage {
		void execute(final int damageAmount);
}

class HitPointDamage implements Damage {
		public void execute(final int damageAmount) {
				member.hitPoint -= damageAmount;
				if (0 < memeber.hitPoint) {
						return;
				}

				member.hitPoint = 0;
				member.addState(StateType.dead);
		}
}

class MagicPointDamage implements Damage {
		public void execute(final int damageAmount) {
				member.magicPoint -= damageAmount;
				if (0 < memeber.magicPoint) {
						return;
				}

				member.magicPoint = 0;
		}
}

void applyDamage(final DamageType damageType, final int damageAMount) {
		final Damage damage = dagmages.get(damageType);
		damage.execute(damageAmount);
}