이번에는
잘못알고 있었던 try catch의 사용법과
duck typing이라는 상속에서 중요한 개념을 알게 되었다.
🎈 try catch
예상가능한 대부분의 에러는 try catch를 사용할 필요가 없다.
나같은 경우에는 예상가능한 예외처리를 할때도 try catch를 사용했는데
잘못 알고있었다.... ㅠ
try catch의 존재 이유
예상 못할 사이드 이펙트의 가능성이 존재 할 때 이를 처리하기 위해 사용하는 구문이다.
try 구문 내에 추상화 메소드?
또한 try 구문 내에 추상화 메소드가 있다면 추상화 메소드 내의
사이드 이펙트가 해당 메소드를 호출한 상위 메소드에도 전파되므로
이는 단일책임원칙에 위배된다.
예상 못할 사이드 이펙트는 해당 메소드 내에서 처리하자.
다시 말해 try 구문 내부에 추상화 메소드를 쓰지말자.
- 예시
function b() {
try {
a(5);
} catch(err) {
alert(err);
return;
}
}
function a(value) {
if(value > 4) {
throw new Error("에러");
}
}
=> a에서 오류가 발생했는데 a 내부에서 처리되는 것이 아니라
b에 까지 전파가 되므로 단일책임원칙에 위배된다.🦆 duck typing
duck typing의 등장
다른 언어와 같이 js에서도 비슷한 행동을 하는 객체들을 하나의 타입으로 묶어 외부에서 공동으로 다루고 싶어하는 요구가 생겼다.
하지만 js는 메소드와 변수들의 모임을 타입으로 정의하여 강제할 수가 없다. 그래서 특정 메소드와 변수들을 가지면 특정 타입으로 간주하는 방법을 사용하였는데 이것이 덕타이핑.
상세 예시
예를들어 "꽥꽥() 함수가 있다면 '오리'로 생각하겠다" 이렇게 틀만 잡아 놓는 것. 물론 꽥꽥 함수 속을 채우는 것은 강제하지 않는다.
꽥꽥 소리를 낼 수 있는 행동에 초점을 두고 타입은 강제하지 않는다는 점이 덕 타이핑의 특징.
예를 들어 사람이 꽥꽥 소리를 낼 수 있어도 덕 타이핑 방식에서는 오리로 간주한다. 이는 오리로 간주하지 않는 정적 타이핑과 다른 동적 타이핑 방식이다.
겪은 문제 상황
내가 짠 코드는
Component 클래스를 상속하는 여러가지 클래스들이 존재했는데
문제는 외부에서 사용할 의도가 보이는 Component의 render() 함수를,
Component를 상속받은 클래스 내부에서 지속적으로 호출하였다는 것이었다.
이는 덕타이핑의 의도에도 맞지 않고, 내부적으로 사용할 것이었다면
Component 자체의 LifeCycle에서 호출해야 했기에 이 의도에도 맞지 않았다.
따라서 2가지 의도 중 하나를 선택해야 했다.
-
메소드를 외부에서 사용할 의도
- 상속을 통해 덕 타이핑을 구현한다는 것은 공통의 특정 메소드를 외부에서 쉽게 사용할 의도를 가짐
- 코드 설계를 보았을 때 render 함수는 외부에서 사용할 의도를 가지고 있음
- 따라서 render 함수는 클래스 내부 constructor에서 반복적으로 호출되어야 할 이유가 없음, 덕 타이핑의 의도에 벗어남
- 따라서 메소드는 외부에서 호출되도록 바꿔야 함
-
메소드를 default 동작으로 사용할 의도
- Component 내부의 default 동작으로 render 함수를 사용할 것이라면 Component 자체의 LifeCycle에서 돌아가도록하여 코드 중복을 막아야함
