이 게시글은 인프런의 유료 강의 스프링 핵심 원리 - 기본편을 수강하며 공부한 내용을 담고있습니다.
저작권에 의해 강의내용에 해당하는 전체 코드는 공개할 수 없습니다.
저작권에 의해 모든 내용을 담을 수 없습니다. 중복 및 반복되는 내용은 생략했습니다.
SOLID 원칙
SOLID 원칙은 아래 다섯 가지 원칙의 첫 글자를 따서 SOLID 원칙이라고 한다.
- SRP(Single Responsibility Principle) : 단일 책임 원칙
- OCP(Open Close Principle) : 개방 폐쇄 원칙
- LSP
- IoC(Inversion of Control) : 제어의 역전
- DI(Dependency Injection) : 의존관계 주입
SRP
SRP(Single Responsibility Principle). 단일책임원칙은 말 그대로 하나의 책임만 지라는 의미이다.
앞서 MemberService 구현체에 다른 객체를 생성하는 기능도 있고, 필요한 로직을 실행하는 기능도 있었다. 하지만 회원과 관련된 로직을 실행하는 기능만 남겨두고 다른 기능을 모두 제거하여 회원 로직 실행만 할 수 있도록 했다.
하나의 책임만 지라는 의미가 애매할 수 있다. 책임의 의미는 그때그때 다르다. 여기서는 회원 로직 실행만 하도록 책임을 지게했다.
DIP
DIP(Dependency Inversion Principle). 의존관계역전원칙은 구체화에 의존하지 말고 추상화에 의존하라는 의미이다.
코딩을 처음 배우면 구현체를 가지고 무언가를 실행하도록 배운다.
1
2
3
Car car = new Bus();
car.take(30); // 30명 탑승
car.go(); // 출발
예를 들어 이런 식으로 new Bus() 를 하여 구현체를 만들고 해당 구현체를 조작(car.take(), car.go() 등을 말함)한다. 지극히 자연스럽다. 하지만 이 코드는 new Bus() 가 아니라 new Sedan() 이 오면 세단에는 30명이 탈 수 없기 때문에 조작부분을 수정해주어야 한다. 또한 car.take() 라는 메서드를 사용하기 위해서는 car 에 어떤 구현체가 담기는지 알고 있어야 사용할 수 있다. 그래서 위 코드는 구현체(구체화)에 의존하고 있는 상태인 것이다. 만약 추상화에 의존하도록 잘 설계되어있다면 car에 어떤 구현체가 오던지 신경쓰지 않고 코드를 작성할 수 있게 된다.
구현체에 뭐가 오는지 몰라도 car 인터페이스의 메서드를 사용할 수 있기만해서 DIP 원칙을 지키는 것은 아니다. 실제로 코드상에서 어떤 구현체가 오는지 몰라야된다.
1
2
3
4
5
6
7
public class MyClass {
Car car;
MyClass(Car car) {
this.car = car
}
//이하 생략
}
이런식으로 car 에 어떤 구현체가 올지 전혀 모르는 상태에서 car 의 메서드를 사용할 수 있어야 DIP 원칙을 잘 지키는 것이다.
OCP
OCP(Open Close Principle). 개방페쇄원칙. 확장에 open 되어있고 변경에 close 되어야 한다는 원칙이다. 쉽게 말하면 코드를 수정하지 않고 기능을 확장할 수 있어야한다는 의미이다.
1
2
3
Car car = new Bus();
car.take(30); // 30명 탑승
car.go(); // 출발
예를 들어 위 코드에서 car 에 저장된 구현체가 Bus가 아니라 Sedan 을 하고 싶다면 new Bus()을 new Sedan() 으로 수정해야한다. 하지만 이렇게 하면 코드를 수정하게 되어 OCP 원칙을 지키지 못한다. OCP 원칙을 지키기 위해서는 다음과 같이 코드를 작성해야 한다.
1
2
3
4
5
6
7
public class MyClass {
Car car;
MyClass(Car car) {
this.car = car
}
//이하 생략
}
이렇게 하면 car 에 저장되는 객체를 변경할 수 있으면서 코드를 수정하지 않아도 된다.
car 예제는 OCP를 설명하기 완벽하지 않기 때문에 맥락만 이해하면 된다.
IoC
IoC(Inversion of Control). 제어의 역전은 내가 작성한 코드를 내가 아니라 프레임워크 등이 제어를 한다는 원칙이다.
예를 들어 내가 Member 클래스와 ‘회원가입’이라는 메서드를 작성을 했다고 하자. 그럼 이 코드를 내가 필요한 곳에서 적절히 호출하여 사용을 할 것이다. 이렇게 하면 내가 코드를 제어하는 것이다.
만약 Member 클래스 그리고 회원가입 메서드를 프레임워크가 알아서 적절히 호출하면 IoC 원칙을 지키게 되는 것이다. 쉬운 예시로 JUnit 테스트 프레임워크가 있다.
JUnit 프레임워크를 이용해 회원가입 메서드를 테스트를 해보면 내가 작성한 테스트 로직을 JUnit 프레임워크 어딘가에 집어넣어서 테스트를 한다. 내 손을 떠나 프레임워크가 코드를 제어하기 때문에 제어의 역전 이라고 부른다.
이전 포스팅 : 예제에 객체지향 원리 적용
다음 포스팅 : 기본 예제에 스프링 기술 적용하기