오랜만에 내가 그린 클래스 다이어그램
ISP 인터페이스 분리 원칙은 위 그림에서 이름이 유래되었다고 한다.
위 그렘이서 User 은 op1 을 , User2 는 op2 를 , User3 는 op3 를 의존하고 있는데 , OPS 클래스가 정적 타입 언어로 작성됬다고 가정해보자.
서로의 의존성 때문에 op2 의 소스 코드가 변경되면 User1 , User3 는 자기와 완전 무방한 코드가 변경되었음에도 불구하고 다시 컴파일 후 배포를 해야한다.
하지만 정적 타입 언어로 해당 클래스 다이어그램을 구현했다고 하면 다시 컴파일 하고 배포하는 상황이 초래되지 않는다고 한다
( ..?? 이게 인터프리턴가 뭐시깅가 때문에 가능한 일인가..??? )
앞의 사례는 정적 , 동적 타입의 언어 즉 언어틔 타입에 의존한다고 한다. 정적 언어는 사용자가 import,use,include 와 같은 타입 선언문을 사용하도록 강제한다.
이처럼 include 선언문으로 인해 의손성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래된다고 한다.
( 음… 그래서 게임은 설계에 그만큼 공을 들여야 하는것인가..? 내가 Api 때 include 에 무지하게 신경썼던 것 처럼… )
루비 , 파이썬과 같은 동적 타입 언어에는 소스 코드에 이런 선언문이 없으며 , 대신 런타임에 추론이 발생한다. 따라서 소스 코드 의존성이 아예 없으며, 이런 특징 때문에 동적 타입 언어는 정적 타입 언어보다 더 유연하고 결합도가 낮은 시스템을 만들 수 있다.
( …….??????? )
필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. 소스 코드 의존성의 경우 이는 분명한 사실인데 , 불필요한 재컴파일과 재배포를 강제하기 때문이다.
여기에서 배울 수 있는 교훈은 불필요한 짐을 실은 무언가에 의존하면 예상치도 못한 문제에 빠진다는 사실이다.
2023.03,14+ 스마트폰 예시:
→ 스마트폰이 크게 추상클래스에 생체인식 , AR 기능 , 뭐 단말칩 그런게 다 있다고 치면 , 그를 상속받는 애들은 모든 기능을 구현해야 하는데 이게 바로 불필요한 짐을 실은 무언가에 의존한 셈이다.
그래서 ISP 의 원칙으로
( 음.. 적당히….. 의지해라… ??? 만약 그게 안되면 큰 모듈의 인터페이스를 분리해서 의존시켜라..?? )