Swift OOP) SOLID원칙 소개

SOLID원칙

객체지향 설계의 중요성을 학교에서나 회사에서 많이들 들어보셨을 거같습니다. 학교에서는 개념적인 부분만 설명했고 .. 머리속에 (솔리드..솔리드) 만 맴돌 뿐이고 정작 적용하는 법에 대해서는 스스로 터득해야 했던 부분이었죠..

인턴때 코드리뷰를 받아보면 근본적으로 이런 부분에서 지적을 많이 받았었습니다. 제 코드에 이런 원칙적인 부분들이 많이 녹아 있지 않다는 것을 느끼게 되었습니다. 사실 개념을 알아도 실천하기가 어려원 원칙들이지만 정리를 통해서 Swift에서 어떻게 적용을 시키는지에 대해서 공부해볼까 합니다.

SOLID의 기원

SOLID 원칙의 역사는 깊다. 나는 1980년대 후반 유즈넷(과거 버전의 페이스북)에서 다른 사람들과 소프트웨어 설계 원칙에 대해 토론하는 과정에서 이들 원칙을 모으기 시작했다. 시간이 지나면서 원칙은 교체되거나 변경되었다. 사라져 버린 원칙도 있다. 어떤 원칙들은 서로 합쳐졌다. 새롭게 추가된 원칙도 있다. 2000년대 초반 나는 안정화된 최종 버전을 내놓았는데, 이 때 원칙들의 순서는 지금과 달랐다.
2004년 무렵, 마이클 페더스(Michael Feathers)가 이메일 한 통을 보내왔는데, 원칙들을 재배열하면 각 원칙의 첫 번째 글자들로 SOLID라는 단어를 만들 수 있다는 내용이었다. 그렇게 SOLID 원칙이 탄생했다.
-교재 클린 아키텍처- 3부 설계 원칙에서

SOLID 원칙이란?

사실 객체지향프로그래밍 자체만 보면 유지보수가 어렵고 또 코드가 혼란스러워 지는 것 자체를 예방해주지는 않습니다. 즉 설계하기 나름입니다. 객체지향프로그래밍의 하나의 확립이 된 설계원칙이 필요했던 것이죠..

SOLID의 설계원칙의 가장 중요한 핵심은 기존의 시스템의 문제점 과 앞으로의 시스템에 닥칠 문제점 이 두가지를 염두에 두고 원칙을 정한게 아닌가 생각이 듭니다.

즉 시스템에 예상하지 못한 변경사항이 발생하더라도, 유연하게 대처하고 이후에 확장성이 있는 시스템 구조를 설계를 하기 위해서 입니다.

“좋은 설계란 시스템에 새로운 요구사항이나 변경사항이 있을때, 영향을 받는 범위가 적은 구조”
-Head First Design Patterns 교재 중-

SOLID는 다섯개의 원칙으로 이루어져 있습니다.

SRP: Single Responsibility Principle. 단일 책임 원칙
하나의 클래스는 하나의 책임만 가져야 한다.
OCP: Open-Closed Principle. 개방-폐쇄 원칙
코드는 확장에는 열려있으나 변경에는 닫혀 있어야 한다.
LSP: Liskov Substitution Principle. 리스코프 치환 원칙
객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위타입의 instance로 바꿀수 있어야 한다.
ISP: Interface Segregation Principle. 인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나 보다 낫다.
DIP: Dependency Inversion Principle. 의존성 역전 원칙
추상화에 의존해야지 구체화에 의존하면 안된다.

5개의 원칙을 포스트를 나누어서 정리하도록하겠습니다. 그리고 이번 공부의 포커스를 아래와 같이 잡아서 공부해보도록하겠습니다.

Swift기반의 적용
단순 이론정리가 아닌 실제 프로젝트 적용 예제