DIP (The Dependency Inversion Principle, 의존 관계 역전의 원칙) Note DIP는 의존 관계 역전이라는 어려운 단어로 해석되고 있지만 실상은 간단하다. 구체화된 클래스를 추상화된 interface 또는 abstract 클래스의 구현 또는 상속 구조로 만들어서 실제 사용할 때 다음과 같은 코드로 사용하는 것으로 이해하면 좋을 것 같다. IFactory factory = new CheeseFactory(); 위에서 CheeseFactory는 IFactory 인터페이스를 구현하고 있음을 가정한 코드이다. 별로 신통해 보이지는 않지만 치즈공장에 버터공장, 마가린공장 등이 생겨났을 때 추상화된 클래스 타입으로 코드를 구성하는 것이 얼마나 도움이 되는지 확인할 수 있다. 위키피디아..
LSP (Liskov Substitution Principle, 리스코프 치환의 원칙) Note LSP는 자식 타입들은 부모 타입들이 사용되는 곳에 대체될 수 있어야 한다는 원칙이다. 즉 부모 클래스가 사용되는 곳에 자식 클래스로 치환 하더라도 문제가 없어야 한다는 의미이다. 여러가지 의미로 생각 해 볼수 있다. 상속받는 자식 클래스는 부모 클래스의 책임을 넘지 말아야 한다는 의미와 자식으로서 제공하는 기능에 대한 제약의 의미 등 제한적인 의미를 말하기도 하고, 사용상의 난해함으로 고생하지 말라는 교훈적인 의미를 말하기도 한다. 파생 클래스 마다 쓰임새가 다르다고 사용법까지 모두 다 다르다면 얼마나 복잡할 것이며, 왜 상속이라는 고수준의 구현 방법을 사용하는가?(게다가 고가의) 파생 클래스의 활용도를 높..
SRP (Single Responsibility Principle, 단일 책임의 원칙) Note 단일 책임의 원칙은 함수나 메소드를 개발할 때의 바람을 객체 차원에서 가지게 될 때 제대로 지켜질 것이다. 우리는 함수나 메소드를 개발할 때 하나의 함수가 하나의 동작에 대해 책임을 다하기를 바랄 것이다. 마찬가지로 우리는 하나의 객체가 단 하나의 "객체" 로서의 책임을 다 할 수 있도록 해주어야 한다. 추상적인 책임이 아닌 시스템 상에서의 책임을 의미함에 주의하자. 데이터를 "저장"하는 책임이라는 추상적인 의미로 객체에 책임을 부여했을 경우를 생각해보자. 단지 저장하나에 대한 책임을 주었음에도 불구하고, 해당 객체는 하나의 객체가 가지는 책임의 범위를 넘어서는 형태가 될 수 있다. 3-1의 그림에서 보듯이 ..
OCP (Open-Closed Principle, 개방폐쇄 원칙) Note 열려 있어야 할 곳(확장)에는 열려 있어야 하고, 닫혀 있어야 할 곳(변경)에는 닫혀 있어야 한다는 원칙. 쉽게 말하자면 확장은 가능하되 변경은 하지 않는 구조로 구성되어야 한다는 원칙이다. 어떻게 만들든 이미 만들어진 코드를 수정하지 않고 상속 받아서 처리하면 OCP가 만족되지 않을까? 그것만으로는 원칙을 지켰다고 말하기는 어려울 것 같다. 객체 지향 5원칙은 개인적인 견해로 개발을 위한 원칙이라기 보다는 설계를 위한 원칙이라 생각한다. 개발 진행 중에 클래스를 수정해야 할 상황이 생겨버렸고, 변경은 하지 않는게 원칙이라고 하니 확장해버리자( = 상속받아서 처리해 버리자). 라는 것은 의도에 맞지 않는 행동이라는 것이다. Log..
ISP(인터페이스 분리의 원칙) Note 인터페이스 분리의 원칙은 기능의 분리로 볼 수 있다. I/O의 기본을 입력과 출력으로 나눈다면 입력이라는 기능과 출력이라는 기능으로 나눌 수 있음을 직관적으로 느낄 수 있다. 이러한 기준은 인터페이스 분리의 원칙에 그대로 적용할 수 있다. 파일의 입력은 Input이라는 인터페이스로 출력은 output이라는 인터페이스로 분리가 가능하다는 뜻이다. 아마도 이렇게 분리된 휼륭한 코드를 본 바 있으리라 생각된다. 자바의 Input, Output API 시리즈가 가장 대표적인 ISP의 표본이지 않을까. 클라이언트가 파일에 Access 하고자 할 때는 입력과 출력을 염두에 둘 것이다. 하지만 대부분의 경우 입력 설계와 출력 설계가 항상 함께이지는 않을 것이고, 사용하지도 않..