SOLID는 고체아닌가요?
Solid는 고체라는 뜻 아닌가요??
놀랍게도 처음 SOLID원칙을 들었을 때에는 실제로 위와 같이 "SOLID는 그냥 고체라는 뜻 아닌가?" 라는 생각을 했었다. 아직 그때 까지는 프로그래머보다는 정상인에 가까운 생각을 했었던 것 같다.
SOLID는 객체 지향 프로그래밍을 개발하기 위해 필요한 5가지의 설계 원칙으로
단일 책임 원칙(SRP),개방-폐쇄 원칙(OCP),리스코프 치환 원칙(LSP),인터페이스 분리 원칙(ISP),의존 역전 원칙(DIP)의 앞글자를 따 만든 설계원칙이다.
이론상으로는 이를 지켜서 코딩을 작성할 경우 소프트웨어의 변경이 용이하고 유지보수와 확장이 쉬워지게 된다.
이를 하나하나 살펴보자.
단일 책임의 원칙(SRP,Single Responsibility Principle)
내가 이해한 SRP를 한줄로 설명하면
각 클래스(모듈)는 하나의 책임(기능)을 가지고 있고 이를 수정하기 위해서는 해당 책임만이 이유가 되어야 한다 라는 원칙이다. 즉 클래스의 수정을 위한 근거는 하나 뿐이라는 뜻이 된다.
여러 요구사항을 반영하는 것이 아닌 하나의 요구사항을 통해서만 코드가 수정된다고 이해할 수도 있을 것 같다.
이렇게 코드를 분리하여 작성할 경우 수정사항이 발생했을 때 어느 부분을 수정해야 하는지 명확해진다는 장점이 존재하게 된다.
하지만 클래스를 보는 관점에 따라서는 책임이 단일한지 아닌지를 판별하는데에 차이가 있을 수 있다고 생각했다.
개방 폐쇄 원칙(OCP,Open-Closed Principle)
개방 폐쇄 원칙의 경우 우리가 짜는 코드는 확장은 열려있고, 변경은 닫혀 있다는 SOLID의 원칙 중 하나 이다.
나는 이를 코드는 귀찮음이 많다 : 많은 일을 하고 싶지만 내가 바뀌기는 싫다.로 이해할 수 있다고 생각했다.
쉽게 생각하면 개발자는 귀찮음이 많기 때문에 수정을 최소화 하되 기존의 기능을 통해 새로운 기능을 사용할 수 있도록 코드를 짜면 된다고 생각했다.
다음과 같은 코드 상에서 서비스 지역이 늘어날 경우 Cron과 Zone에 들어가야 할 값이 계속 달라지므로 Local interface와 같은 식으로 코드를 작성 후 implement를 통해 korea class, japan class등으로 나누어 삽입하여 처리하는 식으로 OCP를 만족 시킬 수 있을 것이다.
그래서 결론적으로는 기존 코드를 수정하지 않고 새로운 기능을 추가 할 수 있어, 코드의 안정성과 재 사용성을 높이기 위해 사용한다고 볼 수 있다.
리스코프 치환 원칙(LSP,Liskov Substitution Principle)
리스코프 치환 원칙은 하위 타입은 상위 타입을 대체할 수 있다는 원칙이다.
만약 코드 상에서 객체를 사용할 때 상위 타입이 하위 타입으로 변경 되어도, 차이점 없이 상위 타입의 public interface를 통해 서브 클래스를 이용할 수 있다는 뜻이다.
이때 자식 클래스가 부모 클래스를 대체하기 위해 부모 클래스에 대한 client의 가정을 준수해야하는 것을 강조 하게 된다.
상위 클래스의 단위 테스트를 하위 클래스 까지 적용하는 방법을 통해 이를 잘 지키는지 쉽게 확인할 수 있다.
이를 통해 우리는 코드의 유연성과 재 사용성을 높일 수 있다고 생각했다.
인터페이스 분리 원칙(ISP,Interface segregation principle)
ISP는 반드시 객체가 자기 자신에게 필요한 기능만을 가지도록 제한 하는 원칙으로 불필요한 상속과 구현을 최소화 함으로써 객체의 불필요한 책임을 배제하는 원칙이다.
클라이언트가 자신이 사용하지 않는 메소드에 의존하지 않도록 최대한 인터페이스를 분리하여 더 작게 제공하여 코드의 유연성을 높이는 데에 장점을 가지고 있다.
의존 역전 원칙(DIP,Dependency Inversion Policy)
DIP는 추상 클래스와 같은 추상화 계층을 통해 의존성을 정의하고 이런 추상화에 의존하여 구체적인 구현 클래스를 작성해야 한다는 것이다.
이렇게 처리함으로써 코드는 결합도를 낮추고 유연성과 확장성을 증가시켜 코드의 재사용성과 테스트 용이성을 높일 수 있게 된다.
이렇듯 SOLID를 공부하게 되며 알게 되는 점은 결국엔 모두 코드의 유연성과 확장성을 제일 우선적으로 고려하여 작성한다는 점이다.
하지만 강의 시간에도 배웠듯이 SOLID원칙을 항상 5개 모두 만족시킬 수는 없다고 생각했다. 이 원칙들은 서로가 서로에게 관계있기 때문에 어느 한 부분을 중점적으로 개발하느냐에 따라 코드의 구조가 바뀔 수도 있다고 생각했다.
여러번 귀찮고 번거롭게 코드를 리팩토링하면서 작업하는 것 보다는 처음 코드를 작성할때 부터 어느 SOLID원칙을 중점적으로 코드를 작성할지 생각하고 이를 잘 지켜 작성하는 것이 좋다고 생각했다.
이렇게 되지 않도록 노력하자
