3.3.3 ~ 3.6.1

3.3 리스코프 치환 원칙

SOLID 원칙 중 리스코프 치환 원칙에 대해 설명한다. 사실 리스코프 치환 원칙은 매우 느슨한 설계 원칙이기 때문에 정상적인 상황에서 우리가 작성하는 코드는 이 설계 원칙을 위반하지 않는다. 따라서 이 원칙은 이해도 쉽고 실제로 적용하는 것도 쉽다.

3.3.1 리스코프 치환 원칙의 정의

• 하위 유형 또는 파생 클래스의 객체는 프로그램 내에서 상위 클래스가 나타나는 모든 상황에서 대체 가능하며, 프로그램이 원래 가지는 논리적인 동작이 변경되지 않으며 정확성도 유지된다.

public class Transporter {
    private HttpClient httpClient;

    public Transporter(HttpClient httpClient) {
        this.httpClient = httpClient;
    }

    public Response sendRequest(Request request) {
        // ...httpClient를 통해 발송 요청하는 코드 생략...
    }
}

public class SecurityTransporter extends Transporter {
    private String appId;
    private String appToken;

    public SecurityTransporter(HttpClient httpClient, String appId, String appToken) {
        super(httpClient);
        this.appId = appId;
        this.appToken = appToken;
    }

    @Override
    public Response sendRequest(Request request) {
        if (StringUtils.isNotBlank(appId) && StringUtils.isNotBlank(appToken)) {
            request.addPayload("app-id", appId);
            request.addPayload("app-token", appToken);
        }
        return super.sendRequest(request);
    }
}

public class Demo {
    public void demoFunction(Transporter transporter) {
        Request request = new Request();
        // ... request 객체에 값을 설정하는 코드 생략...
        Response response = transporter.sendRequest(request);
        //…일부 코드 생략...
    }
}

// 리스코프 치환 원칙
/*
아래 코드에서 하위 클래스는 리스코프 치환 원칙을 따르기 때문에 해당 객체는 상위 클래스 객체가 나타나는 모든 위치에서 대체가 가능함
의조했던 대로 논리적 동작이 변경되지 않으며 정확성도 그대로 유지된다.
*/
Demo demo = new Demo();
demo.demofunction(new SecurityTrasnpoter(/*생략*/));

3.3.2 리스코프 치환 원칙과 다형성의 차이점

리스코프 치환 원칙은 객체지향 특성인 다형성을 단순하게 이용한 것이 아닐까 하는 의구심이 들 수 있다.

• 앞의 코드와 리스코프 치환 원칙의 정의를 기준으로 살펴보면, 리스코프 치환 원칙과 다형성은 보기에는 비슷하지만 실제로는 완전히 다른 의미를 담고 있다.

    @Override
    public Response sendRequest(Request request) {
        if (StringUtils.isBlank(appId) || StringUtils.isBlank(appToken)) {
	        throw new Exception();
				}
		    request.addPayload("app-id", appId);
        request.addPayload("app-token", appToken);
        return super.sendRequest(request);
    }

3.3.3 리스코프 치환 원칙을 위반하는 안티 패턴

3.4 인터페이스 분리 원칙

클라이언트는 필요하지 않은 인터페이스를 사용하도록 강요되어서는 안된다.

• API나 기능의 집합

• 단일 API 또는 기능

• 객체지향 프로그래밍의 인터페이스

3.4.1 API나 기능의 집합으로서의 인터페이스

public interface UserService {
	boolean register(String cellphone, String password);
	boolean login(String cellphone, String password);
	UserInfo getUserInfoById(long id);
	UserInfo getUserInfoByCellphone(String cellphone);
}

// 구현체 생략

• 현재 백그라운드 관리 시스템에서 사용자 삭제 기능이 추가되여아 한다고 판단했고 그에 따라 기능이 추가되기를 원하고 있다.

• 이것을 구현하는 것이 매우 쉽다고 생각할 수 있다. delete하는 인터페이스만 추가하면 되기 때문이다. 하지만 이 방법은 문제를 해결할 수 있지만 일부 보안 위험이 드러나게 된다.

public interface RestrictedUserService {
	boolean deleteUserByCellphone(String cellphone);
	~~~
}

// 구현체 생략(프로바이더 개념)

3.4.2 단일 API나 기능으로서의 인터페이스

public class Statistics {
    private Long max;
    private Long min;
    private Long average;
    private Long sum;
    private Long percentile99;
    private Long percentile999;

    // ...생성자, getter, setter 메서드 생략...

    public Statistics count(Collection<Long> dataSet) {
        Statistics statistics = new Statistics();
        // ...계산 코드 생략...
        return statistics;
    }
}

3.4.3 객체지향 프로그래밍에서의 인터페이스

public class RedisConfig {
    private ConfigSource configSource; // 설정 센터(Zookeeper 등)
    private String address;
    private int timeout;
    private int maxTotal;
    // ..maxwaitMillis, maxIdle, minIdle 등 일부 설정 정보 생략...

    public RedisConfig(ConfigSource configSource) {
        this.configSource = configSource;
    }

    public String getAddress() {
        return this.address;
    }

    // get(), init() 메서드 등은 생략

    public void update() {
        // configSource에서 address, timeout, maxTotal을 읽어온다.
    }
}

public class KafkaConfig {
    // ...
}

public class MysqlConfig {
    // ...
}

3.5 의존 역전 원칙

1. 의존 역전이 뜻하는 것은 어떤 대상 사이의 역전인가? 그리고 어떤 의존이 역전되는 것인가? 여기서 말하는 역전은 무엇인가?

2. 종종 제어 반전과 의존성 주입이라는 두 가지 개념을 접할 수 있는데 이 개념은 의존 역전과 같은 개념에 속하는가? 그렇지 않다면 차이는 무엇인가?

3. 스프링 프레임워크의 IoC는 앞에서 언급한 세 가지 개념과 어떤 관련이 있는가?

3.5.1 제어 반전

public class UserServiceTest {
    public static boolean doTest() {
        // ...
    }

    public static void main(String[] args) {
        // 이 코드는 프레임워크에 넣을 수 있음
        if (doTest()) {
            System.out.println("Test succeeded.");
        } else {
            System.out.println("Test failed.");
        }
    }
}

public abstract class TestCase {
	public void run() {
				if (doTest()) {
            System.out.println("Test succeeded.");
        } else {
            System.out.println("Test failed.");
        }
	}
	public abstract boolean doTest();
}

public class JunitApplication {
	private static final List<TestCase> testCases = new ArrayList<>();

	public static void register(TestCase testCase) {
		testCases.add(testCase);
	}

	public static final void main(String[] args) {
		for(TestCase testCase : testCases) {
			testCase.run();
		}
	}
}

public class UserServiceTest extends TestCase{
		@Override
    public boolean doTest() {
        // ...
    }
}

// 명시적으로 register()를 호출하여 등록하는 대신 설정을 통해 구현 가능
JunitApplicationm.register(new UserServiceTest());

3.5.2 의존성 주입

public class Notification {
    private MessageSender messageSender;

    public Notification(MessageSender messageSender) {
        this.messageSender = messageSender; // new를 사용하는 대신 의존성 주입
    }

    public void sendMessage(String cellphone, String message) {
        this.messageSender.send(cellphone, message);
    }
}

public interface MessageSender {
    void send(String cellphone, String message);
}

// 문자 메시지 발송 클래스
public class SmsSender implements MessageSender {
    @Override
    public void send(String cellphone, String message) {
        // ...
    }
}

public class InboxSender implements MessageSender {
		@Override
		public void send(String cellphone, String message) {
			// ~~~
		}
}

MessageSender messageSender = new SmsSender();
Notification notification = new Notification(messageSender);

3.5.3 의존성 주입 프레임워크

public class Demo {
	public static final void main(String[] args) {
		MessageSender sender = new SmsSender();
		Notification notification = new Notification(sender); //의존성 주입
		
	}
}

3.5.4 의존 역전 원칙

3.6 KISS 원칙과 YAGNI 원칙

3.6.1 KISS 원칙의 정의와 해석