SOLID라고 한다
Single Responsibility Principle
SRP라고 부른다. 하나의 클래스는 하나의 책임만 가져야한다는 것이다. 물론 이 하나의 책임이라는것은 모호하다. 이를 결정하는것은 변경이다. 변경이 있을 때 그 변경이 다른 코드들에 미치는 영향이 적어야한다.
Open Closed Principle
확장에는 열려있으나, 변경에는 닫혀있어야한다는 뜻이다.
뭔가 말이 이상한데, 결과적으로 다형성을 활용하라는 뜻이다.
인터페이스를 구현한 새로운 클래스를 만들어서 그 기능을 구현하면 된다.
하지만 이럼에도 불구하고 구현객체의 변경은 클라이언트 코드변경을 야기한다. 이는 별도의 조립, 설정자를 통해 해결 할 수 있다.
Liskov Substitution Principle
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 의미이다. 예를 들어 인터페이스가 앞으로 가라고 규정했는데, 구현에서 반대로 갈 수는 없다는 뜻이다.
Interface Segregation Principle
특정 클라이언트를 위한 인터페이스 여러개를 만드는것이, 범용 인터페이스를 사용하는것보다 낫다.
인터페이스가 명확해지고, 대체 가능성이 높아진다.
Dependency Inversion Principle
추상화에 의존해야하고 구체화에 의존하면 안된다. 즉 인터페이스에 의존해야지, 실제 구현클래스에 의존하는 코딩을 하면 안된다는 뜻이다.
근데 이거 가능할까? 자바만 가지고는 이 DIP를 지킬 수 없다. 인터페이스와 구현클래스에 의존하는 경우가 많기 때문이다.
그래서 우리는 스프링 config, DI를 통해서 이를 해결한다.
Inversion of Contorl
사실 IOC는 개발원칙은 아니다. 다만 자주 나오는 개념이니깐 정리해두려고 한다.
기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현객체를 호출하고 사용했다. 즉, 구현객체가 프로그램을 제어했었다.
하지만 Appconfig 기법을 사용하면, 이 IOC는 더이상 성립하지 않는다. 프로그램의 제어권은 AppConfig가 쥐고있고, 각 구현객체들은 추상화에만 의존하고 있기에 뭐가 나오는지도 모르고 그냥 가져다가 쓰기만 하는 것이다.
프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.
DI
Dependency Injection.
즉 의존도 주입이란뜻이다.
Appconfig로 해주는게 바로 DI이다.
스프링에서 DI를 인식하는 방법은 몇가지 있는데 이는 다른글에서...
