객체지향적 설계를 하는데 있어 5대 원칙이 있다. 앞글자만 따서 SOLID라고 부른다.
단일 책임 원칙, Single Responsibility Principle
하나의 클래스는 하나의 책임만 가져야한다.
책임이란 기준이 모호하기 때문에 변경 을 책임의 기준으로 삼으면 설계에 용이할 수 있다.
어떠한 역할에 대해 변경사항이 발생했을때, 영향을 받는 기능만 모아둔 클래스라면 동일한 책임을 지닌 기능이 모인 집합으로써 SRP 원칙이 적용된 설계로 볼 수 있을것 같다.
이처럼 변경사항이 있을때, 애플리케이션의 파급 효과가 적으면 SRP 원칙을 잘 따른것으로 볼 수 있다.
개방 폐쇄 원칙, Open Closed Principle
높은 응집도
응집도가 높다는건 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻이다. 같은 책임, 관심사를 기반으로 하나의 객체로 설계하기 때문에 객체에 변경이 발생하더라도 다른 곳에 미치는 영향이 제한적이다.
낮은 결합도
책임과 관심사가 다른 객체 도는 모듈과는 낮은 결합도를 유지해야 한다. 이는 높은 응집도보다 더 민감한 원칙이라고 토비의 스프링에서는 설명하고 있다.
결합도란 하나의 오브젝트가 변경이 일어날때 관계를 맺고있는 다른 오브젝트에게 변화를 요구하는 정도로 설명한다.
즉 낮은 결합도란, 하나의 변경이 발생할 때 다른 모듈과 객체로 변경에 대한 요구가 전파되지 않는 상태라고 할 수 있다.
다른 곳에서는 개방폐쇄 원칙을 확장에 열려있고, 변경에 닫혀있다고도 설명한다.
확장에 열려있다?
모듈의 확장성을 보장하는 것을 의미한다. 새로운 변경사항이 발생했을 때 유연하게 코드를 추가 또는 수정할 수 있기 때문이라고 한다.
변경에 닫혀있다?
객체를 직접적으로 수정하는건 제한해야 한다. 기능이 추가되거나 수정할 때, 객체를 직접적으로 수정해야 한다면 새로운 변경사항에 대해 유연하게 대응할 수 없는 애플리케이션이다.
이는 유지보수의 비용증가가 될 수 있으며, 객체지향적인 설계로 볼 수 없다.
따라서 객체를 직접 수정하지 않고도 변경사항을 적용할 수 있도록 설계해야 한다. 그래서 변경에 닫혀있다고 표현한 것으로 추론된다.
결과적으로 OCP는 추상화를 의미하는 것으로 해석된다. 객체를 추상화함으로써 확장엔 열려있고, 변경엔 닫혀있는 유연한 구조를 만들수 있는 것이다.
OCP를 구현하기 위해서는 DI(Dependency Injection), IoC(Inversion Of Container)가 필요하다.
리스코프 치환 원칙, Liskov Substitution Principle
객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.
하위 클래스는 인터페이스 규약을 지켜서 작성되어야 한다. 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면 LSP가 필요하다.
인터페이스의 메소드를 사용한다고 하면, 어떤 구현체를 사용하든 호출부에서 기대하는대로 동작되어야 한다는 것이다.
인터페이스 분리 원칙, Interface Segragation Principle
범용 인터페이스 하나보다는 특정 클라이언트를 위한 여러 개의 인터페이스 분리가 더 좋다고 한다.
운전자가 자동차를 운전한다. 라는 명제를 객체간 관계로 비유하면 자동차에 대한 인터페이스, 운전자에 대한 인터페이스를 각각 분리하는 것이다.
그럼 운전자는 택시 기사가 될수도 있고, 우버 드라이버가 될수 있다. 자동차는 버스가 될 수도 있고, 택시가 될수도 있고, 스포츠카가 될 수도 있다. 확장성이 커지는 셈이다.
의존관계 역전 원칙, Dependency Inversion Principle
프로그래머는 구체화가 아니라 추상화에 의존해야 한다고 한다. 즉 구현 클래스(구현체)가 아니라 인터페이스(역할)에 의존하라는 이야기이다. 의존관계의 역전은 흔히 DI라고 부르는 스프링에서의 가장 중요한 개념중 하나이다. 이를 통해 개발자는 비지니스 로직에만 집중할 수 있게된다.
