| OOP의 핵심
[ 지난 번 OOP 관련 포스팅 내용 요약 ]
- OOP는 객체 간 상호 관계에 포커스를 맞춘 방법론으로, 추상화, 상속, 다형성, 캡슐화 4가지의 주요 특징이 있다.
- 추상화는 모델링이고, 상속은 확장과 재사용성이며, 다형성은 사용 편의, 캡슐화는 정보 은닉에 해당된다.
- 추상화 단계에서는 클래스 내 응집도를 높이는 게 필요하고, 상속 시에는 클래스 간 결합도에 주의해야 한다. |
- OOP는 풀면 참 복잡했는데, 오늘 배운 수업에서는 분류와 교체라는 단어로 그 핵심을 단순화해 설명했다.
* 현업에 오래 종사했던 강사분은 스파게티 소스에 대해 언급하며,
소프트웨어를 유연하게 만들려면 객체지향 방식이 유용하다 얘기주셨다.
| 분류한다 |
코드를 적절히 잘 분류한다. -> 클래스 |
| 교체한다 |
필요에 따라서 특정 모듈을 통째로 교체하기도 한다. -> DBMS 업체나 라이브러리를 통째로 교체하기도 한다. |
※ 라이브러리와 프레임워크와 아키텍처 간의 상관관계 바로가기
| SOLID 원칙
- 로버트 C. 마틴에 의해 만들어진 원칙
| SRP |
단일 책임 원칙(분류) |
Simple Responsibility principle |
| OCP |
개방 폐쇄 원칙(교체) |
Open/Closed principle |
| LSP |
리스코프 치환 법칙(교체) |
Liskov subsituation principle |
| ISP |
인터페이스 분리 원칙(분류) |
Interface segregation principle |
| DIP |
의존성 역전 원칙(교체) |
Dependency inversion principle |
※ 참조 : 실제 현장에서 사용하는 코드는 아래와 달라 보입니다. 원리를 이해하기 위한 코드로 봐주시면 감사하겠습니다.
1. SRP : 한 클래스는 단일의 책임만 가져야 한다.
SRP가 지켜지지 않은 코드
class PaymentService{
public void pay(Customer customer, Product product) {
if (!isValidatedPrice(customer, product)) {
throw new IllegalArgumentException("charge your money");
}
customer.setMoney(customer.getMoney() - product.getPrice());
}
public boolean isValidatedPrice(Customer customer, Product product) {
if (customer.getMoney() < product.getPrice()) {
return false;
}
return true;
}
public void sendSMS(Customer customer, Product product) {
System.out.println("phone number : " + customer.getPhone());
System.out.println("상품 " + product.getName() + "("
+ product.getProduct_no() + ")이 결제되었습니다.");
}
}
- 고객이 상품을 주문할 때, PaymentService라는 클래스에서 아래와 같이 세가지의 기능을 제공한다고 할 때에
(1) 결제하기 - pay()
(2) 결제가능 여부 확인하기 - isValidatedPrice()
(3) 결제완료 SMS(메세지) 전송하기 - sendTMS()
- 이 세가지 기능은 엄밀히 말하면 서로 다른 기능이라 볼 수 있다.
- 전체 scope이 작은 경우에는 세가지 기능이 묶일 수도 있겠지만, 만약 기능이 더 복잡해지고 확장된다면 세가지를 분리할 수 있다.
클래스를 분리
class PaymentService{
public void pay(Customer customer, Product product) {
if (!PaymentValidation.isValidatedPrice(customer, product)) {
throw new IllegalArgumentException("charge your money");
}
customer.setMoney(customer.getMoney() - product.getPrice());
}
}
class PaymentValidation{
public static boolean isValidatedPrice(Customer customer, Product product) {
if (customer.getMoney() < product.getPrice()) {
return false;
}
return true;
}
}
class SMSService{
public void sendSMS(Customer customer, Product product) {
System.out.println("phone number : " + customer.getPhone());
System.out.println("상품 " + product.getName() + "("
+ product.getProduct_no() + ")이 결제되었습니다.");
}
}
2. OCP : 확장에는 열려있고, 변경에는 닫혀있다.
* if-else의 반복적인 케이스가 보일 때에는 클래스를 분리하는 것이 효과적일 수 있다.
OCP가 지켜지지 않은 코드
class PointService {
public double getPointRate(String category) {
// 구매 카테고리별로 포인트 비율을 다르게 지급
if (category.equals("옷")){
return 0.05;
} else if (category.equals("잡화")) {
return 0.02;
} else if (category.equals("기타")) {
return 0.01;
}
return 0;
}
public double getVIPRate(String category){
// 구매 카테고리 별로 VIP 여부에 따라서 비율을 다르게 지급
if (category.equals("잡화")){
return 0.12;
} else if (category.equals("도서")) {
return 0.08;
} else if (category.equals("기타")) {
return 0.01;
}
return 0;
}
}
- 만약에 포인트 제도가 추가되어, 구매 카테고리 별로 서로 다르게 포인트를 지정한다고 하자.
- 이럴때 카테고리가 위와 같이 한정적이라면 상관이 없겠지만 카테고리가 계속 늘어난다면 문제가 발생할 수 있다.
- 더불어 getPoint()와 getVIPRate()의 카테고리명과 순서가 다른 걸 볼 수 있다.
- 이런 경우 로직이 통일적이지 않아지기 때문에 결과적으로 문제가 발생할 수 있다.
인터페이스를 통한 OCP 확보
interface PointServiceIF{
public abstract double getPointRate(String category);
public abstract double getVIPRate(String category);
}
class Clothe implements PointServiceIF{
@Override
public double getPointRate(String category) {
return 0.05;
}
@Override
public double getVIPRate(String category) {
return 0.00;
}
}
class Book implements PointServiceIF{
@Override
public double getPointRate(String category) {
return 0.12;
}
@Override
public double getVIPRate(String category) {
return 0.25;
}
}
- 인터페이스를 통해서 메소드를 프로토타입으로 만들어 준 후에, 각각의 카테고리를 클래스로 만들어 메소드를 구현하면 OCP를 확보할 수 있다.
3. LSP : 서브타입은 언제나 기반타입으로 교체할 수 있어야 한다.
- 이 부분은 상위 클래스(또는 인터페이스)의 기능과 동일한 기능을 하위 클래스가 상속(또는 구현)하는 가를 말한다.
| 상속 |
is kind of |
하위 클래스는 상위 클래스의 한 분류이다. |
| 구현 |
is able to |
하위 클래스는 상위 인터페이스를 구현할 수 있다. |
- 여기서는 예제를 만들지 않고 대신 예제 링크만 가져왔다.
https://blog.itcode.dev/posts/2021/08/15/liskov-subsitution-principle
- 위 예제에서는, 직사각형 > 정사각형으로 LSP를 설명하는데, 정사각형은 직사각형의 메소드를 모두 동일하게 가져가지 않기 때문에, 사각형 클래스를 만들고 직사각형과 정사각형이 그것을 상속받게 했다.
더보기
- 실무에서는 상속을 많이 사용하지 않는다고 한다.
왜냐하면, 오버라이딩을 했는지 안 했는지 매번 확인하기가 어렵고,
오버라이딩 잘못하면 로직 충돌 (Fragile base class문제)이 일어나기도 하며,
기능을 너무 확장하거나 변경하면 재활용성이 낮아지기 때문이라고 한다.
- 그래서 상속의 대안 및 상속을 잘하기 위해서는
(1) 상위 클래스를 한 클래스만 상속하거나
(2) 클래스 상속이 아닌, 인터페이스로 대체하거나
(3) 상위 클래스와 상호 치환(=동일 기능을 갖도록)이 가능하도록 상속을 해야한다.
4. ISP : 인터페이스도 단일 책임을 갖도록 분리해야 한다.
* 인터페이스를 너무 크게 만들면, 사용하지 않는 메소드들도 구현하도록 해야 한다.
* 실무에서 보면 단일 메소드를 가진 인터페이스들이 있다. > 세분화된 인터페이스로 쪼개서 단일 책임을 갖게 한 것
- 이 부분은 별도로 내용을 추가하지 않고, 바로 앞의 예시로 이야기하겠다.
interface PointServiceIF{
public abstract double getPointRate(String category);
public abstract double getVIPRate(String category);
}
class Clothe implements PointServiceIF{
@Override
public double getPointRate(String category) {
return 0.05;
}
@Override
public double getVIPRate(String category) {
return 0.00;
}
}
class Book implements PointServiceIF{
@Override
public double getPointRate(String category) {
return 0.12;
}
@Override
public double getVIPRate(String category) {
return 0.25;
}
}
- 바로 위의 코드를 보면 "옷"의 경우 안 쓰는 메소드인 getVIPRate()를 구태어 어거지로 구현한 걸 볼 수 있는데,
이유는 인터페이스 안에 메소드를 두 개를 넣어 두어서 두 가지를 모두 구현해야 하기 때문이다.
- 이렇듯 상속은 주의해서 사용하는 게 좋다. 필요하지 않은 메소드까지 구현해야할 수 있고,
너무 많이 확장되고 재사용되다보면 최초에 목적하고 있던 기능에서 많이 동떨어진 메소드가 만들어질 수 있기 때문이다.
- 이러한 문제를 해결하기 위해서는 단일 인터페이스, 곧 단일 메소드를 가진 인터페이스를 만드는 것이 좋다.
interface GeneralPointServiceIF{
public abstract double getPointRate(String category);
}
interface VIPPointServiceIF{
public abstract double getVIPRate(String category);
}
class Clothe implements GeneralPointServiceIF{
@Override
public double getPointRate(String category) {
return 0.05;
}
}
class Book implements GeneralPointServiceIF, VIPPointServiceIF{
@Override
public double getPointRate(String category) {
return 0.12;
}
@Override
public double getVIPRate(String category) {
return 0.25;
}
}
5. DIP : 하위 모듈의 변경이 상위 모듈의 변경을 요구하는 의존성을 끊어내야 한다.
- 개발을 하다보면 보안상의 이슈가 발생한 라이브러리를 다른 라이브러리로 교체해야할 때가 있다고 한다.
- 또는 외주업체에 맡겨 서비스를 추가하는 경우도 있는데, 업체를 변경할 때에도 기존 서비스를 변경해야할 때가 있다고 한다.
- 만약 호텔에 Deposit 금액으로 20만원을 넣어두고, 호텔의 서비스를 사용할 때마다 deposit 금액을 차감시킨다고 하자.
[1] 호텔 비용 정산 클래스 - HotelPaymentService
[2] 고객 deposit에 연결하는 클래스 - HotelDepositAdapter
class HotelPaymentService{
String pay(Customer customer, ServiceRequest serviceRequest){
HotelDepositAdapter hotelDepositAdapter = new HotelDepositAdapter();
int payResult = hotelDepositAdapter.useService(customer, serviceRequest);
if (payResult == -1){
return "Fail";
}
return "Success : left deposit - " + payResult + "(원)";
}
}
class HotelDepositAdapter{
int useService(Customer customer, ServiceRequest serviceRequest){
int possibleDeposit = customer.getDeposit() - serviceRequest.getServicePrice();
if (possibleDeposit < 0) {
return -1;
}
return possibleDeposit;
}
}
- 이 상태에서, 만약 호텔측에서 Deposit 금액 외에 카드를 맡기면 추가적으로 결제가 가능하게 해달라는 요청을 한다면
[1] 호텔 비용 정산 클래스 - HotelPaymentService
[2] 고객 deposit에 연결하는 클래스 - HotelDepositAdapter
[3] 고객 card에 연결하는 클래스 - HotelCardAdapter
- 위와 같이 card를 연결하는 어뎁터 클래스를 하나 더 추가하게 될 수 있다.
- 이런 경우 HotelPaymentService이 이미 HotelDepositAdapter에 의존적이라 코드를 전반적으로 수정해주어야 한다.
- 앞으로 비용 정산 방식이 추가적으로 바뀌게 되면 이 방식은 비효율적이다
class HotelPaymentService{
String pay(Customer customer, ServiceRequest serviceRequest, PaymentType type){
if (type.getType() < 0 || type.getType() >= 2) {
return "PaymentRequest Error : write correct PaymentType";
}
int payResult = -1;
if (type.getType() == 0){
HotelDepositAdapter hotelDepositAdapter = new HotelDepositAdapter();
payResult = hotelDepositAdapter.useService(customer, serviceRequest);
} else if (type.getType() == 1){
HotelCardAdapter hotelCardAdapter = new HotelCardAdapter();
payResult = hotelCardAdapter.useService(customer, serviceRequest);
}
if (payResult == -1){
return "Fail";
}
return "Success : left deposit - " + payResult + "(원)";
}
}
- 이런 경우 아래와 같이 어뎁터 자체가 인터페이스를 구현하도록 하고,
HotelPaymentService가 인터페이스를 바라보도록 하면 해결된다.
enum HotelPaymentType{
DEPOSIT, CARD
}
class HotelPaymentService{
private final HotelDepositAdapter hotelDepositAdapter = new HotelDepositAdapter();
private final HotelCardAdapter hotelCardAdapter = new HotelCardAdapter();
String pay(Customer customer, ServiceRequest serviceRequest){
HotelPaymentIF hotelPaymentIF;
if (serviceRequest.getPaymentType() == HotelPaymentType.DEPOSIT){
hotelPaymentIF = hotelDepositAdapter;
} else {
hotelPaymentIF = hotelCardAdapter;
}
int payResult = hotelPaymentIF.useService(customer, serviceRequest);
if (payResult == -1){
return "Fail";
}
return "Success : left deposit - " + payResult + "(원)";
}
}
interface HotelPaymentIF{
int useService(Customer customer, ServiceRequest serviceRequest);
}
class HotelDepositAdapter implements HotelPaymentIF{
int useService(Customer customer, ServiceRequest serviceRequest){
int possibleDeposit = customer.getDeposit() - serviceRequest.getServicePrice();
if (possibleDeposit < 0) {
return -1;
}
return possibleDeposit;
}
}
class HotelCardAdapter implements HotelPaymentIF{
int useService(Customer customer, ServiceRequest serviceRequest){
if (CardService.useCard(customer, serviceRequest) < 0) {
return -1;
}
return serviceRequest.getServicePrice();
}
}
[ 출처 및 참조 ]
부트캠프 강의를 들은 후 정리한 내용입니다.
[스프링 입문을 위한 자바 객체지향의 원리와 이해]
SOLID https://bottom-to-top.tistory.com/27
위키백과 https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
