Solid 5

[객체지향] SOLID(5) - DIP(의존관계 역전 원칙)

DIP(Dependency Inversion Principle) 의존관계 역전 원칙이란 구체화된 클래스가 아닌 인터페이스나 추상 클래스에 의존해야 한다는 것을 말한다. 인터페이스나 추상 클래스와 관계를 맺음으로 변화하기 쉬운 것(일반 클래스)으로부터 의존을 줄인다. 의존관계 역전 원칙을 따르면, 상위 계층(정책 결정)이 하위 계층(세부 사항)에 의존하는 전통적인 의존관계를 반전(역전) 시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. 이 원칙은 다음과 같은 내용을 담고 있다. 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에 의존해서는 안 된다. 세부 사항이 추상화에 의존해야 한다. 의존관계 역전 원칙은 '상위와..

객체지향 2022.03.01

[객체지향] SOLID(4) - ISP(인터페이스 분리 원칙)

ISP(Interface Segregation Principle) 인터페이스 분리 원칙이란 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 것을 말한다. 인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 사용할 수 있게 한다. 이와 같은 작은 단위들을 역할 인터페이스라고 부른다. 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있다. ISP의 예시를 살펴보자. public interface Phone { void call(); void camera(); void sms(); } public class BasicPhone implements Phone { @Ove..

객체지향 2022.03.01

[객체지향] SOLID(3) - LSP(리스코프 치환 원칙)

LSP(Liskov Substitution Principle) 리스코프 치환 원칙이란 자식 클래스는 자신의 부모 클래스를 대체할 수 있다는 것을 말한다. 리스코프 치환 원칙은 바바라 리스코프가 '자료 추상화와 계층'이라는 제목으로 기초 연설을 한 1987년 콘퍼런스에서 처음 소개한 내용으로, 이 원칙을 엄밀한 용어로 말하자면 (강한) 행동적 하위형화라고 부르는 하위형화 관계의 특정한 사례이다. 이 정의는 1994년 논문에서 다음 원칙을 만들어낸 자료형의 의미론적 상호 처리를 보장하기 때문에 단순한 문법적 관계일 뿐만 아니라 의미론적 관계다. 더보기 q(x)를 자료형 T의 객체 x에 대해 증명할 수 있는 속성이라 하자. 그렇다면 S가 T의 하위형이라면 q(y)는 자료형 S의 객체 y에 대해 증명할 수 있어..

객체지향 2022.03.01

[객체지향] SOLID(2) - OCP(개방-폐쇄 원칙)

OCP(Open-Closed Principle) 개방-폐쇄 원칙이란 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 것을 말한다. 소프트웨어 개발 작업에 이용된 많은 모듈 중, 하나에 수정을 할 때 그 모듈을 이용하는 다른 모듈을 전부 고쳐야 한다면, 이와 같은 프로그램은 수정하기가 어렵다. 개방-폐쇄 원칙은 시스템의 구조를 올바르게 리팩토링 하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는 것이다. 개방-폐쇄 원칙이 잘 적용되면 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다. 개방-폐쇄 원칙의 두 가지 속성은..

객체지향 2022.03.01

[객체지향] SOLID(1) - SRP(단일 책임 원칙)

SRP(Single Responsibility Principle) 단일 책임 원칙이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 한다는 것을 말한다. 여기서 말하는 책임이란 클래스나 모듈을 변경하려는 이유를 의미한다. 다시 말해 어떤 클래스나 모듈은 변경하려는 단 하나의 이유만을 가져야 한다고 볼 수 있다. 단일 책임 원칙은 응집도는 높게, 결합도는 낮게 설계하는 것이다. 단일 책임 원칙의 장점은 책임을 분명히 하여 다른 책임의 변경으로부터 자유로워진다는 것이다. 또한 복잡도를 줄이므로 발생할 버그에 쉽게 대처할 수 있게 된다. 만약 클래스나 모듈마다 책임이 불분명하면 테스트해야 할 것이 많아져 놓칠 수 있는 부분이 많아진다. SRP의 예시를 살펴보자. public cla..

객체지향 2022.03.01