[이벤트 소싱과 마이크로서비스 아키텍처] CH.2 객체지향 설계 원칙

객체 지향의 대명사인 Java를 사용하며 개발자들, 즉 우리들은 절차 지향적인 코드를 작성할 때가 많다.

처음 객체 지향을 공부하던 때, 객체라는 개념이 그리도 낯설었다.

C언어로 코딩 입문을 했기에, 절차적인 코드와 명령에만 익숙했기 때문이다.

객체 지향 기법을 공부하면서, 클래스를 사람으로 바라보려 노력했고 여러 가지 책과 객체 지향 생활 체조 원칙 등의 개념을 숙지하니,

시간이 지나며 훨씬 Java스럽게 작성할 수 있게 된 것 같다.

 

하지만, 아직도 객체 즉 클래스를 설계하고 나누는 건 힘든 일이라 생각한다.

그것은 곧 설계에 대한 영역이라 생각이 드는데, 최근에 LinkedIn 에서 본 토비 님의 글처럼 개발자들은 설계를 직접 다루며 공부할 일이 없기 때문이라는 생각도 든다.

 

정말 기본이 되는 내용이지만 다시 한번 정리해 보자~!

 

---

 

이 챕터에서는 설문조사 기업의 예를 든다.

가벼운 usecase를 코드로 작성한 것을 예로 들고 있는데, 처음엔 책임 없이 하나의 usecase 안에 절차적인 코드를 보여주며 시작한다.

객체 지향 설계 기법을 적용하며, 리팩토링을 해나 가보자.

 

책임 주도 설계.

책임, 역할, 협력으로 표현하는 접근 방법의 한 분야.

객체에 책임을 부여하는 것이 중요하다.

객체의 책임은 곧 "아는 것", "하는 것"이다.

아는 것은 클래스의 속성(필드)이며, 하는 것은 메서드이다. 정말 기본기~

 

객체 지향 생활 체조 원칙에서도 다루 듯이,

객체에 묻지 말고 메시지를 보내라 (Tell Dont Ask)

디미터의 법칙 "Don't talk to stranger"(낯선 사람과 대화하지 마라)

private String secondUncle = me.family.father.family.father.sons[1];
^ 요것 보다는 (체이닝이 너무 심하잖아, 묻지 말구..)

private String secondUncle = me.secondUncle;
^ 요렇게 하면 훨씬 낫지 않을까

 

단일 책임 원칙. (Simple Responsibility Principle)

클래스는 한 가지 일만 수행, 한 가지 이유에 의해서만 변경되어야 한다.

만약 클래스가 변경되는 이유가 여러 개라면 SRP를 위반한 것.

여러 책임을 가진 클래스로 나누고, 연관된 속성을 하나의 클래스로 통합하라!

public class Assign {
	private Customer customer;
	private Surveyor surveyor;
}

 

위와 같이 통합해서~

 

개방/폐쇄 원칙. (Open/Closed Principle)

코드가 자유로우면서도 제한적이어야 한다.

소프트웨어 엔티티는 결국 확장에 대해서 개방적이나, 수정에 대해서 폐쇄적이어야 한다.

 

일례로 WAS인 tomcat을 예로 든다. Java Web Application을 war파일로 만들고 tomcat에 배포하는데, war파일은 톰캣 고유 기능에 영향을 주거나 변경하지 않으므로 변경에 폐쇄적이다. 반대로 새로운 기능을 제공하므로 확장에 개방되어 있다고 볼 수 있다.

 

코드에서도 마찬가지이다. 인터페이스나 상위 클래스에 기본 기능을 두고 구현 클래스나 상속 클래스에서 기능을 확장한다.

확장에 대한 개방은 구현, 상속 클래스에서 기능을 추가할 수 있어야 하고, 수정에 대한 폐쇄는 인터페이스나 상위 클래스의 변화가 하위에 영향을 주지 않아야 한다.

interface Filter {
	boolean isSatisfied(Customer customer);
}

class ContactFilter extends Filter {
	//...
}

class AgeFilter implements Filter {
	// ...
}

class GenderFilter implements Filter {
	// ...
}

이처럼 구현체는 성격에 맞게 해당 추상체를 확장해 나갈 수 있다.

 

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

클라이언트가 상속 클래스를 안정적으로 사용할 수 있는 구조를 설계하는데 도움을 준다.

클라이언트는 클래스의 상속 구조에 관계없이 상위 클래스만 이해하고 사용 가능하다.

 

S가 기반타입 T의 서브타입이면 T 타입의 객체는 프로그램 실행에 문제를 일으키지 않고 S 타입의 객체로 치환이 가능해야 한다.

 

기반 타입 : 클라이언트가 직접 사용하는 타입, 클라이언트는 기반타입의 메서드를 직접 호출

서브 타입 : 기반 타입을 상속한 모든 종류의 클래스

문맥 : 클라이언트가 기반 타입의 메소드를 이용해 서브 타입을 호출할 수 있는 조건

public interface Distributable {
	public List<Assign> distribute(List<Customer> customers, List<Surveyor> surveyors);
}

public class RoundRobinDistributor implements Distributable {
	
    @Override
    public List<Assign> distribute(List<Customer> customers, List<Surveyor> surveyors) {
    	// round robin 방식 알고리즘 구현
    }
}

public class PerformanceDistributor implements Distributable {
	
    @Override
    public List<Assign> distribute(List<Customer> customers, List<Surveyor> surveyors) {
    	// 성과가 좋은 설문 조사원에게 배정하는 방식 알고리즘 구현
    }
}

거의 비슷한 듯~~ 문맥만 이해하면 된다.

 

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

너무 많거나, 관계없는 오퍼레이션을 제공하는 인터페이스를 지양하자.

목적에 맞게!! 잘게 나누자~~

 

Spring Data JPA Interface 구조를 보면,

출처 : https://velog.io/@hoyun7443/JPA%EC%9D%98-%EA%B3%B5%ED%86%B5-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4-JpaRepository%EC%9D%98-%EA%B8%B0%EB%8A%A5%EA%B3%BC-%EA%B5%AC%EC%A1%B0

 

위와 같이 책임에 맞게 여러 interface들이 하위로 상속하는 것을 알 수가 있다.

JPA 세부 구현이 필요 없다면, CrudRepository 만 상속하는 경우도 일부 볼 수 있다.

 

의존성 역전 원칙. (Dependency Inversion Principle)

사실 앞에 나온 개념들과 거의 비슷한 개념.

구체적인 (혹은 자주 변할 수 있는) 클래스를 사용하는 방법을 클라이언트가 직접 알지 못하게 분리하라.

LSP 예제 코드에서 알 수 있었듯이, 클라이언트는 Distributable 인터페이스만 알면 된다. 세부 구현은 알 필요가 없다.

말이 어려울 수도 있지만 결국, 의존성을 interface로 역전시킨 것이다. 구현부를 의존하지 않게 하기 위해!!

 

이를 테면,

interface UserReader {
	fun findBy(userId: Long) : User?
}

class DBUserReader(
	private val jpaUserDao: JpaUserDao
): UserReader {

	override fun findBy(userId: Long): User? {
		return jpaUserDao.findByIdOrNull(userId).toEntity()
	}
}

class HttpUserReader(
	private val userClient: UserClient
): UserReader {

	override fun findBy(userId: Long): User? {
		return runCatching {
			userClient.getUser(userId)
		}.onFailure {
			logger.error(it.message())
		}.getOrNull()
	}
}

// 비즈니스에서..

fun usecase(
	private val dbUserReader: UserReader
) {
	
	// 로직 구현    
}
	
}

요렇게 할 수도 있다.

 

---

 

객체 지향 원칙은 공부만 했지 글로 처음 정리해 본다 ㅎㅎ

비즈니스를 치면서, 좀 더 유념하고 최대한 활용하려 의식해야 한다!! 그래야 늘지~~

 

다음 장은 드디어 이벤트 소싱이다!!