객체 지향 설계 5단계 SOLID에 대해 정리해보려고 합니다.
Why?
객체 지향 설계 5단계가 왜 필요할까?
형식적인 답변으로는 시간이 지나도 변경이 용이하고, 유지보수와 확장이 쉬운 소프트웨어를 개발하는 데 도움이 되기 때문입니다.
실질적인 답변으로는 기존에 남이 만든 클래스를 가져와서 사용하기 쉽고 상속을 통해 확장해서 사용할 수 있기 때문이죠.
SOLID에 대해 알아보자.
유튜브와 기술블로그를 참고해서 내가 이해한 내용을 바탕으로 작성해보았습니다.
SRP ( Single Responsibility Principle ) : 단일 책임 원칙
하나의 클래스는 하나의 책임(기능)을 가지면 좋습니다. 대부분 이렇게 정의되어있지만 모호한 부분이 있어 다시 정의하려고 합니다. 모듈이 변경된다면 이유가 한가지여야 한다.
해당 모듈이 여러 대상 또는 액터들에 대해 책임을 가져서는 안되고, 오직 하나의 액터에 대해서만 책임을 져야 한다는 것이다.
예시 > UserService 클래스가 있고 Email과 PW를 받아 사용자 추가 모듈이 있다면 여기서 Email검증 혹은 PW암호화는 책임을 분리해서 구현해야한다.
OCP ( Open-Closed Principle ) : 개방 폐쇄 원칙
한줄로 애기하자면, 기능을 추가할 때는 기존의 코드를 변경하지않아도 된다.
확장에 대해 열려있고, 기존 코드에 대한 수정에 대해서는 닫혀있어야 한다는 원칙.
내가 코드를 추가해야되는 데 계속해서 기존 코드를 수정하는 케이스는 정말 안좋은 케이스이다.
예시 > Animal 클래스를 상속받는 클래스로 강아지/고양이/소로 해서ㄹ Animal이라는 클래스는 수정이 없도록 한다.
LSP ( Liskov Substitution Principle ) : 리스코프 치환 원칙
하위 타입은 상위 타입을 대체할 수 있어야 한다는 것이다. 즉, 해당 객체를 사용하는 클라이언트는 상위 타입이 하위 타입으로 변경되어도, 차이점을 인식하지 못한 채 상위 타입의 퍼블릭 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다는 것이다.
예시 > 부모클래스 Square(사각형), 상속받은 자식클래스로 Rectangle(정사각형)일 경우, 리스코프 치환 원칙을 지켜진다.
ISP ( Interface Segregation Principle ) : 인터페이스 분리 원칙
목적과 관심이 각기 다른 클라이언트가 있다면 인터페이스를 통해 적절히 분리해줄 수 있다.
클라이언트의 목적과 용도에 적합한 인터페이스를 제공하는 것이다.
예시 > 클라이언트의 기대에 따라 동물이라는 Interface로 정의해서 하위 클래스로 고양이/강아지로 받는 것보다 기어다니기/짖기 Interface로 구성해서 강아지는 기어다니기/짖기를 상속받고, 고양이는 기어다니기만 상속받아 구현한다.
DIP ( Dependency Inversion Principle ) : 의존 역전 원칙
고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되며, 저수준 모듈이 고수준 모듈에 의존해야한다.
고수준 모듈 : 입력과 출력으로부터 먼(비즈니스와 관련된) 추상화된 모듈
저수준 모듈 : 입력과 출력으로부터 가까운(HTTP, 데이터베이스, 캐시등과 관련된) 구현 모듈
예시 > 토끼의 먹이를 Carrot / Apple로 구체화된 객체를 가지지말고 그 상위 개념인 Vegetable( 좀 더 추상화된 ) 객체를 가져야된다.
