객체 지향 설계의 5가지 원칙 - S.O.L.I.D

S.O.L.I.D

S.O.L.I.D 원칙이란 객체지향 프로그래밍을 진행하면서 지켜야 할 5가지의 원칙을 의미합니다. 각각 원칙의 앞글자를 가져와서 SOLID라고 표기하며 소프트웨어의 유지보수 및 확장을 더 쉽게 할 수 있게 하고 또한 코드의 복잡성을 제거하여 리팩토링에 소요된 시간을 줄이며, 개발의 생산성을 높일 수가 있습니다.

---

단일 책임 원칙 - S.R.P (Single Responsibility Principle)

하나의 클래스는 하나의 기능(책임)만을 가져야 한다.

하나의 클래스는 하나의 책임만을 가지도록 설계를 해야합니다. 여기서 책임이란 하나의 기능을 의미하며 해당 기능에 대해서 수행하도록 설계를 해야 합니다. 하나의 클래스의 여러 가지의 기능이 들어가게 설계를 진행한다면 기능을 변경(수정)할 경우에 수정해야 할 코드가 많아지게 됩니다. A부분을 수정하면 B, B를 수정하면 C처럼 여러 가지의 기능이 클래스에 들어가 있다면 하나의 기능에 대해서 연쇄적으로 책임을 지게 될 수 있기에 프로그램의 유지보수성 위해서 하나의 클래스는 하나의 책임만을 가지는 것을 원칙으로 합니다.

---

개방 폐쇄 원칙 - O.C.P (Open/Closed Principle)

클래스는 확장에는 열려있고 변경(수정)에는 닫혀 있어야 한다.

개방 폐쇄 원칙은 기존 코드를 수정하지 않고 새로운 기능을 추가 하는 즉, 소프트웨어 구성요소들(클래스, 모듈, 함수 등)이 확장에 대해서는 손쉽게 설계하도록 권장하고 있습니다. 하지만 클래스의 내부의 변경이나 수정에 대해서는 닫히도록 설계하는 것을 권장하고 있으며 만약 클래스 내부 구조나 기능에 대해서 쉽게 변경이 가능하다면 해당 클래스 내부의 함수, 혹은 외부에서 해당 클래스의 함수를 호출하고 있는 코드들에 대해서도 이미 선언한 구문들에 대한 수정이 필요하게 됩니다.  

---

리스코프 치환 원칙 - L.S.P (Liskov Substitution Principle)

자식 클래스는 언제나 부모 클래스를 대체 할 수 있어야 한다.

리스코프 치환 원칙은 OOP 특징중 하나인 다형성 원리를 이용하기 위한 원칙이기도 합니다. 리스코프 치환 원칙을 설명하자면 Bird 클래스를 구현하고 fly()라는 함수를 구현하여 새가 날아다니는 것을 구현했을 때 해당 클래스를 상속하여 Penguin 클래스를 구현할 때 부모의 fly() 함수를 그대로 상속받지 않도록 하고 있습니다. (펭귄은 하늘을 날지 못하기에 fly() 함수를 정상적으로 사용할 수 없다) 다형성은 하나의 객체나 인스턴스로 여러 타입의 객체를 다룰 수 있도록 설계를 할 것을 요구하는데 방금처럼 Penguin의 fly를 구현한다면 업캐스팅 시에 부모(Bird)의 fly() 함수를 사용했을 때 기능이 의도한 대로 흘러가지 않기 때문입니다. 리스코프 치환 원칙을 준수하면 상속 구조가 있는 프로그램에서 부모 클래스의 참조를 자식으로 대체해도 프로그램의 정상적인 동작을 기대할 수 있게 됩니다. 이는 코드의 재사용성을 높이는 기대효과가 있습니다.

---

인터페이스 분리 원칙 - I.S.P (Interface Segregation Principle)

하나의 인터페이스로 여러 타입의 객체를 다룰 수 있어야 한다.

단일 책임 원칙이 클래스의 책임에 대해서 단일 책임을 요구한다면 인터페이스 분리 원칙은 인터페이스의 단일 책임을 요구합니다. 인터페이스를 설계할 때는 인터페이스를 각 기능에 알맞게 설계하도록 권장하고 있으며 각 기능에 대해서 적합한 인터페이스를 구현할 것을 원칙으로 하고 있습니다. 인터페이스 분리 원칙을 적용하면 인터페이스의 크기를 작게 유지하여 각 인터페이스가 명확한 목적을 가지게 됩니다. 이는 클래스가 불필요한 의존성을 줄이며 시스템의 유연성과 재사용성을 높일 수 있습니다.

---

의존 역전 원칙 - D.I.P (Depency Inversion Princliple)

상위(고수준)의 모듈은 하위(저수준)의 모듈에 의존해서는 안되며 둘 다 추상화에 의존해야 한다.

구체적인 구현보다는 인터페이스나 추상 클래스에 의존하도록 함으로 모듈 간의 결합도를 낮추고 유연성을 높이는데 목적이 있습니다. 결합도를 낮게 유지한다면 모듈을 교체하거나 수정하는데에 편리하고 이는 소프트웨어의 확장성과 유지보수성을 향상합니다.

---