SOLID Principles (SOLID 원칙)
객체지향 프로그래밍의 4가지 특징 이외에 지켜야 할 다섯 가지 원칙입니다. 글 작성은 원칙을 먼저 하게 되었지만 객체지향의 4가지 특징에 대해 먼저 공부하고 원칙을 공부하는 것이 좋다고 생각합니다.
공부하면서 느낀 바로는 캡슐화, 상속, 추상화, 다형성은 OOP를 이루는 핵심적인 요소에 더 가깝고 5가지 원칙은 코드를 보다 유연하고 간결하고 유지보수 하기 쉽게 만들기 위한 것 같습니다.
즉, 5가지 원칙을 준수하지 않는다면 복잡하고 유지보수가 어려워질 수 있습니다.
S: Single Responsibility Principle
단일 책임 원칙
하나의 일만 담당해야 하고 하나의 변경 이유만 가져야 한다는 원칙입니다.
극단적으로 설명하자면 계산기 배경을 변경하기 위해 더하기 클래스를 수정해야 하는 일은 없어야 한다는 것입니다.
지키기 위한 tip
- class에 역할에 맞는 이름을 붙이는 것과 그 이름에 and가 들어가야 할 거 같다면 클래스를 분리하는 것으로 보다 쉽게 SRP를 지킬 수 있습니다.
- 테스트를 작성하면서 하나의 기능을 테스트하기 위해 다른 기능들이 계속 필요하다면 많은 책임을 지고 있을 가능성이 높습니다.
예를 들어 로그인 과정에서 로그 관리 등도 담당하거나 호출해야 한다면 로그인 클래스가 로그 관리와 관련된 책임이 있을 수 있습니다.
O: Open/Closed Principle
개방/폐쇄 원칙
OCP는 확장에는 열려있고 수정에는 닫혀있어야 한다는 원칙입니다.
지키기 위한 tip
- 상속을 받거나 프로토콜을 따르는 등의 추상화가 동반된다면 기존의 코드 수정 없이 필요한 기능을 추가적으로 확장해나갈 수 있게 됩니다.
- 새로운 기능을 추가할 때 switch, if문 등을 피하고 다형성을 가지도록 하는 것도 좋습니다.
- 다른 객체에 대한 의존성을 클래스 내부에 가지는 것이 아닌 의존성을 주입하는 방식으로 원칙을 지키기 쉽게 만들 수 있습니다.
L: Liskov Substitution Principle
리스코프 치환 원칙
리스코프는 사람 이름입니다. 하위 코드는 언제나 상위 코드를 대신할 수 있어야 한다는 것으로 이를 통해 일관성 있고 예측 가능한 코딩이 가능합니다.
지키기 위한 tip
- 부모 클래스의 기능을 무조건 지원하고 예외처리하거나 제외시키지 않도록 합니다.
- 특정 타입에 지나치게 종속적이지 않도록 합니다.
I: Interface Segregation Principle
인터페이스 분리 원칙
인터페이스란 스위프트에서는 프로토콜이라고 부르는 것으로 너무 큰 인터페이스는 불필요한 메소드까지 따르게 하므로 작게 나누어야 한다는 원칙입니다.
지키기 위한 tip
- 각 역할에 따라 인터페이스를 분리하고 하나의 인터페이스엔 필요한 메서드를 최소한으로 작성합니다.
- SRP와 더불어 너무 작고 작은 단위로 작성하게 되면 오히려 코드가 복잡해질 수 있다고 생각합니다. 적당한 균형을 찾는 것이 중요합니다.
D: Dependency Inversion Principle
의존성 역전 원칙
하위 수준 모듈에 의존하면 안 되며 상위 수준 모듈, 하위 수준 모듈 모두 추상화에 의존해야 한다는 원칙입니다.
이는 구체적인 클래스에 의존하지 않음으로써 클래스가 변경되더라도 다른 클래스나 상위 클래스에 영향을 끼치지 않도록 만들게 됩니다.
지키기 위한 tip
- 프로토콜 등을 이용해 필요한 기능만 주입받습니다.
- 의존성 주입을 받습니다.
마무리
전체적으로 굉장히 비슷한 느낌이 드는 원칙들입니다. 하나를 확실히 지키면 다른 원칙은 자연스레 지켜지는 경우도 있는 듯 합니다. 대신 각 원칙은 무엇에 초점을 두냐에 따라 나뉘었으며 키워드로 정리하면 다음과 같을 수 있습니다.
원칙 | 키워드 |
---|
SRP | 하나의 책임 |
OCP | 확장성 |
LSP | 일관성 |
ISP | 인터페이스의 세분화 |
DIP | 추상화에 의존 |
솔리드 정리본 잘 보고 갑니둥둥두루둥