[OOP] SOLID 정리

 앞선 게시글에서 객체지향 설계 원칙인 SOLID Principle에 대해 알아보았다. 이 글에서는 SOLID Principle을 사용해야 하는 이유, 그리고 각각의 원칙들의 연관성에 대해 조금 살펴본다.

 

왜 설계 원칙이 중요할까?

 

요구사항이 얼마나 변경되는지..

 사용자 요구사항의 변경은 정말 시시때때로 이루어진다. 요구사항이 바뀌면 한숨부터 나오는 것은 사실이다. 그렇지만 이러니저러니 해도 결국 그 요구사항을 받아들여 프로그램을 수정해야 한다. 왜? 결국 프로그램을 사용하는 건 사용자니까. 이런저런 요구사항을 전부 수정하다보면 코드가 꼬이는 일도 비일비재하다. 초기에는 깨끗한 설계도 이것저것 덧붙이다 보면 지저분해지기 마련이니까.

 

 그래서 더더욱 유지보수성과 확장성이 높으면서도 버그가 적게 발생할 수 있는 좋은 설계가 중요하다. SOLID Principles를 준수함으로써 프로그램의 유연성 & 확장성 & 재사용성 증가, Coupling 감소, Cohesion 증대 등 유지보수성을 높일 수 있는 좋은 설계를 할 수 있다. 최대한 유지보수하기 쉽고, 코드를 수정하더라도 다른 것이 영향받지 않게 해야 조금이라도 더 빠른 시간 내에 요구사항을 반영할 수 있게 되고, 조금이라도 더 적은 버그가 터질 것이다.

 

 

 

정리 & SOLID 원칙의 연관성

1. Single Responsibility Principle
   • 하나의 class는 단 하나의 책임만 가져야 하며, 변경의 이유가 그 책임의 변화 하나뿐이다.
   • 테스트 용이성 증가, 코드 변경 effect 최소화
2. Open Closed Principle
   • 모든 compoment는 수정에는 열려 있고 확장에는 닫혀 있어야 한다.
   • 코드를 변경하지 않으면서 기능 변경 및 확장할 수 있다.
   • 확장성 & 유연성 증가
3. Liskov Substitution Principle
   • subtype이 항상 supertype으로 치환될 수 있어야 하며 치환 시 프로그램 동작에 변화가 없어야 한다.
   • 이를 위해 overriding 시 supertype method의 동작 의도를 크게 수정해서는 안 된다.
   • 확장성 증가, Cohesion 감소
4. Interface Segregation Principle
   • 모든 object는 자신이 사용하지 않는 method를 가진 interface에 depend하면 안 된다.
   • 이를 위해 interface를 작은 단위로 분리해야 한다.
   • 재사용성 증가, Coupling 증가, Cohesion 감소
5. Dependency Inversion Principle
   • dependency를 가지는 component는 concretion이 아닌 abstraction에 의존해야 한다.
   • 확장성 & 유연성 증가, Coupling 감소

 

 Single Responsibility Principle와 Interface Segregation Principle은 유사하다. Single Responsibility Principle은 모든 class가 하나의 책임만 가질 만큼 쪼개야 하고, Interface Segregation Principle은 Interface의 concretion이 사용하지 않는 method가 없을 만큼 쪼개야 한다.(꼭 필요한 method만 포함해야 한다.)

 

 Open Closed Principle과 Dependency Inversion Principle, Liskov Substitution Principle은 연관관계가 있다. Dependency Inversion Principle은 abstraction에 의존해야 한다는 원칙이며, Liskov Substitution Principle은 subtype이 supertype으로 치환되어야 한다는 원칙이다.Open Closed Principle은 abstraction을 통해 수정에는 열려 있고 확장에는 닫힌 구조를 만든다.

 Liskov Substitution Principle에 의해 upcasting했을 때 프로그램 동작의 동등성을 보장하기 때문에 abstraction을 사용할 수 있다. abstraction을 사용할 수 있기 때문에 Dependency Inversion Principle과 Open Closed Principle을 사용할 수 있다.

 

 

 

마무리

 SOLID Principle은 객체지향 설계를 할 때 중요한 원칙이다. 그렇지만 이 원칙들을 항상 지키기는 어렵다. 설계에 시간도 많이 걸리고 모든 원칙들을 항상 100% 준수할 수 있는 것도 아니기 때문이다. 오히려 SOLID Principle을 적용하려 할 때 코드가 더 복잡해지는 경우도 많으며, SOLID Principle 이외에 다른 원칙들도 많다. 따라서 상황에 따라 적절한 판단이 필요하다.

 따라서 좋은 설계에 대한 많은 예시들을 보고 더 좋은 방법이 없는지 끊임없이 고찰해야 한다.