SOLID 원칙
SOLID는 로버트 마틴이 정의한 객체 지향 설계의 5가지 원칙을 말합니다. 학교에서 소프트웨어공학 수업시간에 배울 당시에는 학문적인 부분에서만 나올 것 같은 내용이라 생각했지만, 객체 지향 프로그래밍을 할 때 깔끔한 코드 작성을 위해 지켜야함을 깨달았습니다.
단일 책임 원칙(SRP, Single Responsibility Principle)
하나의 클래스는 하나의 책임만을 가져야 한다는 원칙입니다. 어떤 클래스를 변경해야 하는 이유는 하나뿐이어야 합니다. 이 문장만 들으면 잘 이해가 가지 않을 것입니다.
예를 들어 어떤 클래스가 고객정보를 저장하는 부분과 서비스를 제공하는 부분을 모두 포함한다고 생각해봅시다. 훗날에 방대한 코드를 작성해보니 고객정보를 저장하는 부분이 변경될 필요가 발생하였습니다. 하지만, 해당 부분을 수정하다보니 전혀 건들 필요가 없는 서비스 부분에도 영향을 미치게 되어버렸습니다.
이를 해결하기 위해서는 어떻게 해야할까요? 고객의 정보를 저장하는 부분과 서비스를 제공하는 부분을 분리하여 별도의 클래스로 만들어야 합니다. SRP에서 말하는 책임은 예시에서 '고객정보 저장'과, '서비스 제공'이고, 하나의 클래스에 2가지의 책임이 존재했기 때문에 SRP를 위반한 것이라고 할 수 있습니다.
개방 폐쇄 원칙(OCP, Open-Closed Principle)
소프트웨어 요소들은 확장에는 열려있으나 변경에는 닫혀있어야 한다는 원칙입니다. 확장은 가능하지만 변경은 하지 않는 방법이 있는지 의문이 들 수 있습니다. 객체지향 언어의 꽃이라 할 수 있는 다형성이 있다면 충분히 할 수 있습니다.
고객 정보를 저장하는 클래스가 필요하다고 가정해봅시다. 만약, 처음부터 고객 정보 저장방식을 메모리에 저장하는 방식으로 설정했다고 하면, 후에 메모리에서 데이터베이스로 변경하고자 할 때, 연관된 모든 클래스들을 수정하는 결과롤 가져올 수 있습니다.
하지만 고객 정보 저장을 담당하는 인터페이스를 생성한 후, 이 인터페이스를 이용하여 메모리 저장 방식과 DB 저장방식을 별도로 구현한다면 해결할 수 있습니다. 다른 클래스에서 고객 정보를 저장하고자 할 때, 인터페이스를 기준으로 클래스를 작성한다면 후에 구현체가 변경되더라도 영향을 주지 않기 때문에 OCP가 지켜집니다.
리스코프 치환 원칙(LSP, Liskov Substitution Principle)
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다고 정의되어 있습니다. 이름과 설명만 들으면 전혀 감이 안잡힙니다. 간단히 말하자면, 상속관계에 있는 두 클래스에 대해, 자식 클래스가 사용된 곳에선 언제나 부모 클래스로 대체 가능해야하고, 인터페이스를 구현한 구현체의 자리에는 인터페이스가 대체 가능해야 한다는 의미입니다.
인터페이스 분리 원칙(ISP, Interface Segregation Principle)
클라이언트는 자신이 사용하지 않는 메소드에 의존관계를 맺으면 안된다고 정의되어 있습니다. SRP와 비슷한 내용인데, 인터페이스가 많을수록 특정 클라이언트를 위한 인터페이스가 세분화되고, 후에 인터페이스가 변경되는 상황이 발생해도 다른 클라이언트에 영향을 주지 않을 가능성이 크다는 것입니다.
예를들어 어떤 인터페이스가 자동차에 대한 운전법, 정비방법을 모두 포함한다고 가정해봅시다. 개발을 진행하다보니 운전 방법에 대한 인터페이스가 변경될 필요성을 느끼고 변경을 시도하는데, 이것이 정비 방법에도 영향을 미치게 됩니다. 이는 ISP 원칙을 어긴 것이고, 해결하기 위해서는 운전법 인터페이스, 정비방법 인터페이스를 분리하는 것입니다.
의존관계 역전 원칙(DIP, Dependency Inversion Principle)
마지막 SOLID원칙은 제 생각에는 가장 중요하다고 생각되는 원칙입니다. 프로그램은 추상화에 의존해야지 구체화에 의존하면 안된다는 원칙입니다. 후에 나오는 의존성 주입이 이 원칙을 따르는 방법이기 때문에 자세한 설명은 DI 부분을 참고하시면 됩니다.
