객체지향 설계원칙

개발자라면 객체지향 설계, SOLID라는 용어를 본 적이 있을 것이다. 하지만 딱 용어 정도만 들어보고 각각이 무엇인지 또 어떤 것들을 말하는 것인지 잘 알지 못하는 사람도 있을 것이다.
기록해두고 잊을만하면 다시 보며 항상 머릿속에 상기시키도록 하자.

설계는 항상 어렵다. 과연 이 클래스의 역할은 무엇이고 어디까지 수행하는 게 맞을까?
어떤 식으로 설계를 해야 한눈에 보기 쉬운, 아름다운 코드를 작성할 수 있을까. 항상 고민된다.
객체지향 프로그래밍의 5가지 원칙을 지키며 변경에 용이하고, 유지 보수, 확장이 좋은 소프트웨어를 개발하기 위해 노력해 보자.

SOLID 원칙

1. 단일 책임 원칙
2. 개방 폐쇄 원칙
3. 리스코프 치환 원칙
4. 의존 역전 원칙
5. 인터페이스 분리 원칙

그래서 그게 뭔데?

간략하게 알아보자. 상세한 내용은 각각 하나씩 조금 더 자세하게 작성해둔 글을 찾아가자.(추가 예정)

단일 책임 원칙 (Single Responsibilty Principle)

클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙

public class Payment {
	final static int CARD = 1;
	final static int CASH = 2;
	int paymentType;

	void pay() {
		if (this.paymentType == 1) {
			// 카드로 결제한다.
		} else {
			// 현금으로 결제한다.
		}
	}
}

위와 같은 코드가 있다고 하자. pay method에서 카드와 현금일경우를 모두 처리하려고 해서 단일 책임 원칙을 위반한다.

abstract class Payment {
	abstract void pay();
}
class CardPayment extends Payment{
	void pay(){
    // 카드로 결제한다.
    }
}
class CashPayment extends Payment{
	void pay(){
    // 현금으로 결제한다.
    }
}

하나의 추상 클래스를 두고 각각의 클래스가 자신의 특징에 맞게 method를 구현해서 사용하는것으로 변경 가능하다.

개방 폐쇄 원칙 (Open-Closed Principle)

기존 코드의 확장에는 열려있어야 하고, 변경에는 닫혀있어야 한다.

class User{
// something to do
}
class Card{
// something to do
}
class Cash{
// something to do
}

해당 클래스가 있다고 가정해보자. 사용자는 결제 방식(카드, 현금)에 따라서 취해야할 행동이 달라진다. 만약 삼성페이와 같은 새로운 결제 수단이 추가된다면, User에게 바로 영향이 간다.
이러한 변화에는 닫혀있어야 한다. 이러한 경우, Pay라는 클래스/인터페이스가 추가된다면, 새로운 결제 수단이 추가가 되어도, Pay의 확장으로 개방되어 있고, User의 입장에서는 변경에 닫혀있을 수 있다.

리스코프 치환 원칙 (Liskov Substitution Principle)

하위 타입의 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 한다.

하위 클래스는 상위 분류의 한 종류이다.

사촌형은 삼촌의 한 종류인가..? 아니다.

고래는 포유류의 한 종류인가..? 맞다.

인터페이스 분리 원칙 (Interface Segregation Principle)

클라이언트의 목적과 용도에 적합한 인터페이스 만을 제공해야 한다.

사람 Interface가 있다고 생각해 보자. 해당 Interface에는 출근하기, 사격하기 같은 기능이 있을 것이다.
그럼 해당 Interface(사람)를 어린이 Class와 군인 Class 가 Implements 했다고 가정해 보자.
군인 Class의 사격하기 기능이 변경된다면, 어린이 Class에도 영향을 미친다. 이는 분리되어야 한다.
ISP는 단일 책임 원칙과 유사한 느낌이 있다.

의존 역전 원칙 (Dependency Inversion Principle)

만약, 의존 관계를 가지게 된다면, 변하기 어려운 것에 의존하자.

자동차와 타이어가 있다고 하자.
눈이 펑펑 내리고 있어 스노우 타이어를 장착하도록 자동차가 설계되어 있다.
하지만 날씨가 따뜻해져, 스노우 타이어 대신 일반 타이어로 변경하도록 결정하였다.
그렇다면, 스노우 타이어를 일반 타이어로 코드 변경만 하면 끝이 나는가?
아니다. 의존하고 있던 자동차의 코드도 모두 영향을 받는다.
스노우 타이어와 일반 타이어를 타이어로 추상화했다면, 문제가 없다.

마무리

결론적으로 하고 싶은 말은 추상화와 다형성인 것 같다.
아주 간략한 개념만을 소개했다. 각각의 내용을 자세하게 이해하고 설명하자면 길다.
각각의 자세한 내용은 별도로 포스팅한 글로 찾아가서 확인하자.