instanceof를 지양하는 이유는 무엇인가

[sangjun121]

.

[sangjun121]

결론

객체지향 관점에서 instanceof를 남용한다면, 다형성을 제대로 활용하지 못하고, 구체 클래스에 의존하는 코드가 쉽게 발생할 수 있습니다. 구체적으로 말하자면, 객체의 타입을 검사해서 분기한다는 의미는, 객체 자체에게 책임을 맡기는 것이 아닌 외부에서 객체의 구체 타입을 알아야 한다는 것을 의미합니다. (이는 결국 if-else를 객체지향 프로그래밍에서 지양하는 이유와 상통합니다.)

구체 예시

저희가 레벨1에서 진행했던 장기의 기물은 Piece라는 추상화 타입 아래, 구체 클래스인 King, Pawn,등과 같이 구체 클래스로 표현하였습니다. 즉, 이 덕분에 각 객체가 구체적으로 어떤 타입인지 조건문을 피하고, Piece.move()를 호출하는 외부 객체에서는 내부 구현을 모르게 구현할 수 있었습니다. 즉, 결국 추상화를 통해 구체 클래스에 의존하는 것을 지양하고 다형성을 이용해 변경가능성에 대해 대비할 수 있었습니다.

결국, instanceof도 이와 같은 맥락에서 구체 클래스인 King,Pawn,등을 외부 객체에서 알수밖에 없게 만듭니다. instanceof를 작성하는 외부 객체가 Piece라는 추상화의 구체클래스를 알고 있기 때문에, 추후 구체클래스가 추가된다면, 해당 외부객체 역시 변경되야하는 문제가 생깁니다. 이는 결국 객체지향 원칙인 개방 폐쇄 원칙을 위반합니다.

[haeyoon1]

1. 구체 클래스에 대한 의존도가 높아집니다.

instance of를 사용하면 코드가 추상 타입뿐만 아니라 그 하위의 구체 클래스들까지 직접 알아야 합니다.
이는 추상화에 의존하기보다 구현체에 의존하는 구조가 되기 때문에, 추상화의 의미가 약해집니다.

2. 다형성을 제대로 활용하지 못합니다.

객체지향적으로는 호출부가 공통 인터페이스나 추상 타입만 바라보고,
구체 타입별 동작은 각 구현 클래스 내부에서 처리하는 것이 자연스럽습니다.

그런데 외부에서 instance of로 타입을 검사한 뒤 구현체 별 동작을 직접 작성하면, 객체의 책임이 외부로 새어 나가게 됩니다.
결과적으로 다형성을 활용하지 못하고 여러 분기 코드가 발생하게 됩니다.

3. 분기 처리가 늘어나 OCP를 위반하기 쉽습니다.

instance of를 사용해 구현체 별 로직을 외부에서 분기 처리하면, 새로운 구현체가 추가될 때마다 기존 조건문도 함께 수정해야 합니다.
이는 "확장에는 열려 있고 변경에는 닫혀 있어야 한다"는 OCP 원칙에 어긋나게 됩니다.

[Uechann]

1. 개방폐쇄 원칙(OCP) 위반

개방-폐쇄 원칙을 깨뜨리게 된다.

새로운 타입이 추가될 때마다 instanceof 분기를 수정해야 한다.

2. 다형성이 죽는다.

객체를 나눈 이유에 대한 다형성이 사라지게된다.

3. 추상화가 깨진다.

호출부에서 구현에 대한 디테일을 알아야 하는 강한 결합도가 생긴다.