의존성 역전 원칙(Dependency Inversion Principle) 의존성 역전 원칙이란 객체는 저수준 모듈보다 고수준 모듈에 의존해야한다는 원칙이다. 고수준 모듈: 인터페이스와 같은 객체의 형태나 추상적 개념 저수준 모듈: 구현된 객체 고/저수준 모델의 정의는 위와 같다. 위 정의를 의존성 역전 원칙에 대입하면, 객체는 객체보다 인터페이스에 의존해야 한다로 치환할 수 있다. 즉, 가급적 객체의 상속은 인터페이스를 통해 이루어져야 한다는 의미로 해석할 수 있다. 코드로 보는 의존성 역전 원칙 예시를 통해 의존성 역전 원칙을 준수하지 않은 경우와 준수한 경우 어떠한 차이가 있는지 코드를 통해 알아보자. 의존성 역전 원칙을 준수하지 않은 코드 import java.util.Random; /** * 한..

인터페이스 분리 원칙(Interface Segregation Principle) 인터페이스 분리 원칙이란 객체는 자신이 호출하지 않은 메소드에 의존하지 않아야 한다는 원칙이다. 구현할 객체에게 무의미한 메소드의 구현을 방지하기 위해 반드시 필요한 메소드만을 상속/구현하도록 권고한다. 만약 상속할 객체의 규모가 너무 크다면, 해당 객체의 메소드를 작은 인터페이스로 나누는 것이 좋다. 위 그림은 규모가 너무 큰 객체를 상속했을 때 발생하는 문제와, 이를 인터페이스로 분리하여 해결하는 방법을 도식화한 것이다. 왼쪽과 오른쪽 객체가 가운데 객체를 각각 상속할 경우, 왼쪽 객체는 필요한 메소드가 모두 구현되기 때문에 아무런 문제가 없다. 그러나 오른쪽 객체의 경우, Method1을 제외한 나머지 메소드는 필요가 ..

리스코프 치환 원칙(Liskov Substitution Principle) 리스코프 치환 원칙은 부모 객체와 이를 상속한 자식 객체가 있을 때 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체할 수 있다는 원칙이다. 객체지향 언어에선 객체의 상속이 일어난다. 이 과정에서 부모/자식 관계가 정의된다. 자식 객체는 부모 객체의 특성을 가지며, 이를 토대로 확장할 수 있다. 하지만 이 과정에서 무리하거나 객체의 의의와 어긋나는 확장으로 인해 잘못된 방향으로 상속되는 경우가 발생한다. 리스코프 치환 원칙은 올바른 상속을 위해 자식 객체의 확장이 부모 객체의 방향을 온전히 따르도록 권고하는 원칙이다. 코드로 보는 리스코프 치환 원칙 리스코프 치환 원칙을 설명할 때 많이 사용하는 예제로 직사각형과..

개방-폐쇄 원칙(Open-Closed Principle) 개방 폐쇄 원칙이란 객체를 다룸에 있어서 객체의 확장은 개방적으로, 객체의 수정은 폐쇄적으로 대하는 원칙이다. 한 마디로, 보여줄 건 보여주고, 숨길 건 숨긴다는 의미이다. 좀 더 쉽게 말하자면, 기능이 변하거나 확장 가능하지만, 해당 기능의 코드는 수정하면 안된다는 뜻이다. 그런데 조금 모순적이게 느껴지지 않나? 이처럼 개방-폐쇄 원칙은 각 객체의 모듈화와 정보 은닉의 올바른 구현을 추구하며, 이를 통해 객체 간의 의존성을 최소화하여 코드 변경에 따른 영향력을 낮추기 위한 원칙이다. 예를 들어, 구형 POS 기에 새로운 결제 기능을 덧붙이는 방법을 고안해본다. /** * 포스 클래스 * * @author RWB * @since 2021.08.14..

객체지향 5원칙 올바른 객체지향 설계를 위해 수립한 원칙이 있으며, 이 다섯 가지 원칙을 통틀어 객체지향 5원칙이라 명명한다. 필수로 적용하지는 않지만, 적어도 이 규칙을 준수하면 준수할수록 올바르게 설계된 객체지향이라 할 수 있다. 이 다섯가지 원칙은 아래와 같다. 1. 단일 책임 원칙(Single Responsibility Principle) 2. 개방-폐쇄 원칙(Open-Closed Principle) 3. 리스코프 치환 원칙(Liskov Substitution Princicple) 4. 인터페이스 분리 원칙(Interface Segregation Principle) 5. 의존성 역전 원칙(Dependency Inversion Principle) 각 원칙의 영어 앞글자를 따 SOLID 원칙이라고도 ..

다형성(Polymorphism) 객체지향 언어는 동일한 이름을 가진 메소드를 허용하지 않는다. 예를 들어, "먹는다"는 동작이 구현된 메소드가 있다고 가정하자. 먹는다는 동일한 동작이 구태여 두 개나 구현될 필요는 없다. 이러한 관점에서 본다면 메소드의 고유 아이덴티티라고도 불릴 수 있는 메소드명의 유니크화는 어쩌면 당연하다. 하지만 조금 생각해보면 좀 이상하다. JAVA는 타입에 죽고 타입에 산다. Javascript와 달리 파라미터에 아무타입이나 넣을 수 없기 때문에, 정해진 타입 이외의 무언가를 넣으면 컴파일 단계에서 가차없이 컷한다. One for One! 하나의 파라미터는 반드시 하나의 타입만을 가진다. 그말인즉슨, 동일한 메소드는 존재할 수 없으니, 해당 메소드에 입력할 수 있는 각각의 파라미..