"리스코프 대체 원칙"
"기반 클래스는 구현 클래스로 대체 가능해야 한다."

기반 클래스 - Map, List, Set 등..
구현(파생) 클래스 - HashMap, HashTable, ArrayList, CheckedList, HashSet 등..

역시나 책을 아무리 읽어봐도 이해하기가 어렵다. 내 맘대로 해석해본다.

아래와 같은 상황이 "기반 클래스가 구현 클래스를 대체하고 있는 것"이다. 라고 해석했다.

보통 저렇게 습관적으로 써와서 그런가 원칙 설명이 쉽게 이해가 되지 않는다.
책 예제에 있는 소스를 실행해보면,

지원하지 않는다고 예외가 떨어졌고 결국 기반 클래스인 List는 구현 클래스를 대체하지 못했다.

Arrays.asList()은 배열을 List타입으로 변환해준다. 소스를 보면 분명 new ArrayList(obj) 를 리턴하고 있지만 저 ArrayList는 Arrays클래스의 내부 클래스인 ArrayList이다.


그 ArrayList는 AbstractList를 상속받고 있지만 add() 메서드 기능을 재구현 하지 않았다. 그래서 AbstractList의 add() 메서드가 호출되면서 UnsupportedOperationException을 던지게 되어있다.

왜 저런식으로 한건지 모르겠다. 왜 AbstractList는 구현 클래스들이 add()를 구현하게끔 강제하지 않았는지..
저런식으로 Exception을 던져버리면 하위 클래스에서는 add() 메서드의 중요함은 모른채 동작되고 있을 것이다.

사실 List는 굉장히 많이 사용되고 있는 Interface이고 List의 add() 메서드는 거의 그림자 처럼 따라다니며 사용되는데 List를 상속받은 AbstractList부터 add() 메서드는 사용될 수도, 안될 수도 있게 되버렸다.

"자식(구현)은 부모(기반)의 유산(메서드) 중 일부를 거부하면 안된다."
거부하면 위와 같이 기반 클래스는 구현 클래스를 대체할 수 없게 된다. 라는 뜻으로 이해하려 한다.


5개 밖에 안되는 원칙을 보고 있는데 뒤죽박죽 헷갈린다. 나름대로 공부하고 정리할겸 포스팅을 하는건데 내용을 보면 모르는것 투성이라서 너무 창피하다..;; 어디서 무림 고수가 등장해서 리플하나 남겨주지 않으시려나..^^

'Design Patterns' 카테고리의 다른 글

Strategy.  (0) 2012.03.03
"OCP", Open Closed Principle  (0) 2012.02.26
"ISP", Interface Segrehation Principle  (1) 2012.02.26
"DIP", Dependency Inversion Principle  (0) 2012.02.26
"SRP", Single Responsibility Principle  (0) 2012.02.25

+ Recent posts