Java SOLID

Basic Java

Word count: 1.1kReading time: 6 min

 2022/12/25   Share

객체 지향 설계의 5가지 원칙(SOLID)

Created Time: September 22, 2022 12:38 PM
Last Edited Time: September 22, 2022 1:57 PM
References: https://mangkyu.tistory.com/194

좋은 객체 지향 설계의 5가지 원칙(SOLID)(!!!)

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

SRP: 단일 책임 원칙(single responsibility principle)
OCP: 개방-폐쇄 원칙 (Open/closed principle)
LSP: 리스코프 치환 원칙 (Liskov substitution principle)
ISP: 인터페이스 분리 원칙 (Interface segregation principle)
DIP: 의존관계 역전 원칙 (Dependency inversion principle)

SRP: 단일 책임 원칙(single responsibility principle)

한 클래스는 하나의 책임만 가져야 한다.
하나의 책임이라는 것은 모호하다.(클 수 있고, 작을 수 있다.)
문맥과 상황에 따라 다르다.중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
예) UI 변경, 객체의 생성과 사용을 분리
단일 책임 원칙을 지키면 → 책임과 관심이 다른코드를 분리하고, 서로 영향을 주지 않도록 추상화함으로써 → 변경이 필요할때, 수정할 사항 대상이 명확해진다

예시

잘못된 예시
(한 클래스가 복수의 행동에 대해 책임지는 경우)

@Service
@RequiredArgsConstructor
public class UserService {

	private final UserRepository userRepository;

	public void addUser(final String email, final String pw) {
		final StringBuilder sb = new StringBuilder();

		for(byte b : pw.getBytes(StandardCharsets.UTF_8)) {
			sb.append(Integer.toString((b & 0xff) + 0x100, 16).substring(1));
		}

		final String encryptedPassword = sb.toString();
		final User user = User.builder()
				.email(email)
				.pw(encryptedPassword).build();

		userRepository.save(user);
	}
}

출처: https://mangkyu.tistory.com/194 [MangKyu's Diary:티스토리]

올바른 예시
(한 클래스가 단일 행동에 대해서만 책임지는 경우)

@Component
public class SimplePasswordEncoder {

	public void encryptPassword(final String pw) {
		final StringBuilder sb = new StringBuilder();

		for(byte b : pw.getBytes(StandardCharsets.UTF_8)) {
			sb.append(Integer.toString((b & 0xff) + 0x100, 16).substring(1));
		}

		return sb.toString();
	}
}

@Service
@RequiredArgsConstructor
public class UserService {

	private final UserRepository userRepository;
	private final SimplePasswordEncoder passwordEncoder;

	public void addUser(final String email, final String pw) {
		final String encryptedPassword = passwordEncoder.encryptPassword(pw);

		final User user = User.builder()
				.email(email)
				.pw(encryptedPassword).build();

		userRepository.save(user);
	}
}

OCP: 개방-폐쇄 원칙 (Open/closed principle)

소프트웨어 요소는 확장에는 열려 있으나 수정에는 닫혀 있어야 한다
추상화를 위해 다형성을 활용해보자
- 인터페이스를 지킨 새로운 구현체로 확장가능
- 기존 코드 변경없이 확장
인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
지금까지 배운 역할과 구현의 분리를 생각해보자
조립해주는 설정자에서만 바꿔주면 >> 클라이언트는 바꿔줄필요없으므로 원칙 지킴
변하는 것들은 숨기고, 변하지않는것들에 의존하여, 결합도와 의존도를 낮추는것이 목적

예시

잘못된예시
(비밀번호 암호화 클래스 변경시→ 새로운 암호화 정책과 무관한 UserService에서 SHA256PasswordEncoder 부분의 수정이 반드시 필요해진다)
(확장엔 닫혀있고, 수정에 닫혀있지않다.)

@Service
@RequiredArgsConstructor
public class UserService {

	private final UserRepository userRepository;
	private final SHA256PasswordEncoder passwordEncoder;

	...
    
}

올바른예시
(비밀번호 암호화 클래스 변경시→ 새로운 암호화 정책과 무관한 UserService에서는 수정할 부분이 없다.해당 인터페이스(PasswordEncoder)의 구현체 모두가 적용가능하다.)
(확장에는 열려있고, 기존 수정에는 닫혀있다)

@Service
@RequiredArgsConstructor
public class UserService {

	private final UserRepository userRepository;
	private final PasswordEncoder passwordEncoder;

	public void addUser(final String email, final String pw) {
		final String encryptedPassword = passwordEncoder.encryptPassword(pw);

		final User user = User.builder()
				.email(email)
				.pw(encryptedPassword).build();

		userRepository.save(user);
	}
}

추상화시 런타임과 컴파일타임의 의존성은 다르다.
런타임 의존성이란 애플리케이션 실행 시점에서의 객체들의 관계를 의미하고, 컴파일타임 의존성이란 코드에 표현된 클래스들의 관계를 의미한다.
UserService는 컴파일 시점에 추상화된 PasswordEncoder에 의존하고 있지만 런타임 시점에는 구체 클래스인 SHA256PasswordEncoder에 의존하고 있는 것이다.

LSP: 리스코프 치환 원칙 (Liskov substitution principle)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
단순히 컴파일에 성공하는 것을 넘어서는 이야기
간단한 예시
자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리 더라도 앞으로 가야함

자세한 예시
직사각형(길이가 다름이 정의됨)를 부모로하는 자식인 정사각형 클래스가있다. 직사각형에서 resize()라는 함수를 통해 사이즈조절할수있게하였다. 하지만 resize()는 같은 길이일때 에러가 발생하도록 만들었다.

public void resize(Rectangle rectangle, int width, int height) {
    rectangle.setWidth(width);
    rectangle.setHeight(height);
    if (rectangle.getWidth() != width && rectangle.getHeight() != height) {
        throw new IllegalStateException();
    }
}

이를 사용하는 클라이언트에서는 정사각형(자식관계)에서 resize()를 호출하면 에러가 날수밖에없다. 부모 클래스와 자식 클래스의 행동이 호환되지 않으므로 리스코프 원칙에 위반된다.

→ LSP를 지킬려면 항상 클라이언트 입장에서 상위,하위 올바르게 기능이 호환되는지 봐야한다.

ISP: 인터페이스 분리 원칙 (Interface segregation principle)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음
인터페이스가 명확해지고, 대체 가능성이 높아진다.

예시

비밀번호 암호화에 입력한 비밀번호가 동일한지 검사하는 로직을 추가한다고하자.
아래 예시는 isCorrectPassword가 구현되긴했지만, 다른곳에서 이것을 쓸려면 SHA256PasswordEncoder 전체를 주입받아야한다. → 기능을 분리의 필요성

@Component
public class SHA256PasswordEncoder implements PasswordEncoder {

	@Override
	public String encryptPassword(final String pw)  {
		...
	}

	public String isCorrectPassword(final String rawPw, final String pw) {
		final String encryptedPw = encryptPassword(rawPw);
		return encryptedPw.equals(pw);
	}
}

다음과 같이 별도의 인터페이스를 만들고 필요한 곳에 해당 인터페이스를 구현하도록 만들면, 다른 기능을 가지지 않은 꼭 필요한 기능만 주입받아 활용이 가능하다. → 인터페이스 분리 원칙 준수

public interface PasswordChecker {
    String isCorrectPassword(final String rawPw, final String pw);
}

@Component
public class SHA256PasswordEncoder implements PasswordEncoder, PasswordChecker {

	@Override
	public String encryptPassword(final String pw)  {
		...
	}
  
	@Override
	public String isCorrectPassword(final String rawPw, final String pw) {
		final String encryptedPw = encryptPassword(rawPw);
		return encryptedPw.equals(pw);
	}
}

DIP: 의존관계 역전 원칙 (Dependency inversion principle)(!!!)

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
즉, 클라이언트가 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻(!!!)
앞에서 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다! 구현체에 의존하게 되면 변경이 아주 어려워진다.
예시)
그런데 OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
MemberService 클라이언트가 구현 클래스를 직접 선택 (구현부에 적혀있으면 의존성 존재..)
- DIP 위반
  1
  2
  3
  public class MemberService{
  MemberRepository m = new **MemoryMemberRepository**(); // 인터페이스도 의존하지만, new로 동시에 구현 클래스직접선택함
  }
객체 지향의 핵심은 다형성
다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
다형성 만으로는 OCP, DIP를 지킬 수 없다.뭔가 더 필요하다.(이게 아마 스프링 빈..autowired?등등???)

객체 지향 설계와 스프링

스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원
- DI(Dependency Injection): 의존관계, 의존성 주입
- DI 컨테이너 제공
클라이언트 코드의 변경 없이 기능 확장
쉽게 부품을 교체하듯이 개발

정리

모든 설계에 역할과 구현을 분리하자
모든 설계는 추상화를 의존하는것이 바람직하다.
애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할수있도록 만드는 것이 좋은 객체 지향 설계다
이상적으로는 모든 설계에 인터페이스를 부여하자…(모든 부품 갈아낄수있네…)
기능을 확장할 가능성없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.(꿀팁)

Next Post

Null-Optional-Empty
Previous Post

SpringProject-TrackingPost-CH06

CATALOG

1. 객체 지향 설계의 5가지 원칙(SOLID)
2. 좋은 객체 지향 설계의 5가지 원칙(SOLID)(!!!)
3. 객체 지향 설계와 스프링
4. 정리

