SOLID원칙은 소프트웨어 디자인의 기본 원칙으로, 객체 지향 프로그래밍에서 사용된다.
하나의 클래스는 하나의 책임만 가져야 한다.
즉, 클래스는 하나의 기능만 수행해야 한다.
클래스간의 결합도가 낮아져 유지보수가 용이해 진다.
하나의 클래스가 하나의 기능만 수행하므로 코드의 가독성이 높아지고 코드의 재사용성도 높아진다.
클래스 수가 많아진다.
이는 클래스를 구분하기 위한 이름을 지어야하고, 클래스간의 관계를 파악하기 위해 추가적인 시간과 노력이 필요하다는 의미이다.
확장에는 열려 있고, 변경에는 닫혀 있어야 한다.
이 원칙은 기존 코드를 변경하지 않고 새로운 기능을 추가할 수 있도록 설계해야 함을 의미한다.
새로운 요구사항이나 기능이 추가될 때 기존 코드를 변경하지 않고 새로운 코드를 추가할 수 있다.
이는 코드의 재사용성과 유지보수성을 높이는 장점이 있다.
기존 코드의 변경이 최소화되므로 신뢰성이 높은 코드를 작성할 수 있다.
또한 개발자들은 기존 코드를 이해하고 수정할 필요 없이 새로운 코드를 작성할 수 있어 생산성이 향상된다.
인터페이스 설계에 대해 추가적인 고민이 필요하다.
OCP를 너무 지나치게 적용하면 코드의 복잡도가 증가할 수 있으므로 적절한 수준에서 적용해야 한다.
자식 클래스는 부모 클래스의 역할을 대체할 수 있어야 한다.
이는 다형성을 지원하기 위해 필요하다
LSP를 사용하면 부모 클래스를 사용하는 코드가 자식 클래스에서도 동일하게 작동하므로 코드의 가독성이 높아지고, 재사용성도 높아진다.
자식 클래스에서 새로운 기능을 추가하거나 기존 기능을 변경해도 부모 클래스를 사용하는 코드에 영향을 주지 않으므로 유지보수가 용이해진다.
LSP를 따르기 위해서는 인터페이스 설계에 대한 추가적인 고민이 필요하다.
또한 LSP를 지키지 않으면 다형성을 지원하지 못하고, 가독성과 유지보수성이 떨어지는 문제가 발생할 수 있어 인터페이스를 잘 설계하고 상속 관계를 적절하게 구성해야한다.
클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야한다.
이 원칙은 인터페이스의 분리로 인한 결합도를 낮추기 위해 필요하다.
ISP를 따르면 인터페이스가 작고 단순해지므로, 인터페이스의 구현체를 변경하더라도 클라이언트 코드에 영향을 주지 않는다.
또한 ISP를 따르면 인터페이스를 사용하는 클라이언트 코드가 필요한 기능만 사용하므로, 코드의 가독성이 높아지고, 재사용성도 높아진다.
하지만 ISP를 따르기 위해서는 인터페이스 설계에 대한 추가적인 고민이 필요하다.
ISP를 지나치게 적용하면 인터페이스 수가 많아져 코드의 가독성이 떨어지는 문제가 발생할 수 있다.
추상화된 것은 구체적인 것에 의존하면 안된다. 이 원칙은 의존성을 역전시켜 유연한 코드를 작성할 수 있도록 돕는다.
DIP를 따르면 구체적인 구현체가 아니라 추상화된 인터페이스에 의존하므로, 구현체를 변경하더라도 클라이언트 코드에 영향을 주지 않는다.
인터페이스를 사용하는 클라이언트 코드와 구현체가 독립적으로 개발될 수 있으므로, 코드의 재사용성과 유지보수성이 높아진다.
DIP를 따르기 위해서는 인터페이스 설계에 대한 추가적인 고민이 필요하다.
DIP를 지나치게 적용하면 인터페이스 수가 많아져 코드의 가독성이 떨어지는 문제가 발생할 수 있다.
적절한 수준에서 추상화와 구체화를 조절하는 것이 중요하다.
내 생각엔 모든 원칙에 장점에는 유지보수와 가독성의 키워드가 있는 것 같고 단점에는 인터페이스, 설계의 고려, 지나친 적용의 문제가 있는 것 같다.
아무래도 객체지향 설계 원칙이다보니 장단점이 비슷비슷한 것 같기도..
아무튼 잘 적용해 나가서 더욱 객체지향적인 코드를 짤 수 있도록 해보자