안녕하세요 Jercy입니다. 오늘은 OOP에서 가장 핵심적인 개념에 대해 알아보려고 합니다.
많은 개발자들이 OOP를 배울 때 클래스를 만들고 사용하는 것에 초점을 맞추다 보니, OOP의 핵심 개념을 놓치기 쉽습니다. 특히 상속(Inheritance)을 OOP의 가장 중요한 개념으로 생각하는 경우가 많은데요, 이는 잘못된 생각입니다.
상속은 코드의 재사용을 위해 사용되기도 하지만, 이는 강한 커플링을 야기합니다. 상속을 통해 부모 클래스의 기능을 그대로 물려받기 때문에, 부모 클래스의 변경이 자식 클래스에 큰 영향을 미치게 되죠. 이는 코드의 유지보수를 어렵게 만듭니다.
그렇다면 OOP에서 가장 중요한 개념은 무엇일까요? 바로 추상화(Abstraction)입니다.
예를 들어 iOS 개발에서 UIViewController를 상속받아 자신만의 ViewController를 만들 때, 이를 UIViewController의 기능을 확장하는 것으로 보기보다는 추상적인 UIViewController를 구체화하는 것으로 보는 것이 더 나은 접근 방식입니다. 마찬가지로 UIView를 상속받아 커스텀 뷰를 만들 때도, UIView의 기능을 확장하기보다는 추상적인 UIView를 구체화하는 것으로 보는 것이 좋습니다.
이렇게 상속을 추상적인 것을 구체화하는 도구로 보게 되면, 잘못된 상속을 하지 않을 가능성이 높아집니다. 상속보다는 컴포지션(Composition)을 사용하는 것이 더 나은 선택일 때가 많죠.
이상으로 OOP에서 추상화의 중요성에 대해 알아보았습니다.
생각해볼 점:
1.
지금까지 본인이 OOP를 활용할 때 상속을 어떻게 사용해왔나요?
2.
상속 대신 컴포지션을 활용할 수 있는 방법에는 어떤 것들이 있을까요?
3.
추상화의 개념을 적용했을 때 어떤 장점이 있을까요?
저의 답변:
1.
상속은 신중하게 사용해야 합니다. 꼭 필요한 경우가 아니라면 다른 방법을 먼저 고려해보는 것이 좋겠네요.
2.
프로토콜을 활용하거나, 의존성 주입(Dependency Injection)을 사용하는 것도 좋은 방법이 될 수 있습니다.
3.
추상화를 적절히 활용하면 코드의 가독성과 유지보수성이 향상됩니다. 또한 시스템의 복잡도를 줄일 수 있죠. 모듈화가 잘 된 코드를 작성할 수 있게 됩니다.
SOLID란, 로버트 C. 마틴이 객체지향 설계가 잘된 코드들에서 공통적으로 가지고 있는 특징들을 5가지로 정리한 것입니다.
1.
SRP(Single Responsibility Principle) - 단일 책임 원칙
클래스는 하나의 책임(역할)만 가져야 한다는 원칙입니다.
예를 들어, 하나의 클래스가 2개 이상의 일을 하고 있다면 이는 단일 책임 원칙에 위배되는 것이므로, 해당 클래스를 2개의 클래스로 분리해야 합니다.
2.
OCP(Open Closed Principle) - 개방 폐쇄 원칙
코드는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다는 원칙입니다.
즉, 새로운 기능 추가는 쉽게 되어야 하지만, 기존 코드의 변경은 최소한으로 이루어져야 한다는 의미입니다.
3.
LSP(Liskov Substitution Principle) - 리스코프 치환 원칙
객체지향 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 원칙입니다.
슈퍼클래스를 사용하여 작성한 코드는 서브클래스의 인스턴스를 넣어도 정상 동작해야 한다는 뜻입니다.
4.
ISP(Interface Segregation Principle) - 인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다는 원칙입니다.
인터페이스는 클라이언트 별로 잘 분리되어 있어야 하며, Swift에서는 프로토콜로 이를 구현합니다.
5.
DIP(Dependency Inversion Principle) - 의존관계 역전 원칙
추상화에 의존해야지 구체화에 의존하면 안된다는 원칙입니다.
이는 iOS 개발에서 TableView와 DataSource, Delegate를 통해 잘 구현되어 있습니다.
테이블뷰가 특정 뷰컨트롤러나 데이터에 의존하는 것이 아니라, 반대로 뷰컨트롤러와 데이터가 테이블뷰에 의존하도록 설계되어 있습니다. 즉, 의존관계가 역전된 형태입니다.
SOLID 원칙에 맞게 코딩하면 자연스럽게 디자인 패턴의 형태를 갖추게 됩니다. 디자인 패턴들은 대부분 SOLID 원칙을 활용하고 있기 때문입니다.
또한 기존의 디자인 패턴을 상황에 맞게 변경 적용할 때에도, SOLID 원칙을 알고 있다면 어떤 부분을 바꿔야 할지 판단하기 쉬워집니다.
따라서 SOLID 원칙을 잘 이해하고 익히는 것만으로도, 별도로 디자인 패턴을 암기할 필요 없이 좋은 객체지향 설계가 가능해집니다.
생각해볼 점:
•
SOLID 각 원칙이 실제 iOS 개발에서 어떻게 적용되고 있나요?
•
SOLID 원칙을 지키지 않은 코드의 문제점은 무엇일까요?
•
SOLID 원칙이 디자인 패턴과 어떤 관계가 있을까요?
제 답변:
•
SOLID는 iOS 개발의 근간을 이루는 중요한 원칙들입니다. TableView의 DataSource/Delegate, Protocol의 활용 등 iOS SDK 전반에 걸쳐 SOLID 개념이 적용되어 있습니다.
•
SOLID를 지키지 않으면 코드의 가독성과 유지보수성이 크게 떨어지며, 새로운 기능 추가나 변경이 어려워집니다. 버그 발생 가능성도 높아집니다.
•
SOLID는 객체지향 디자인 패턴의 기반이 되는 원칙입니다. 디자인 패턴들은 SOLID 원칙을 잘 활용하여 만들어진 것이라 볼 수 있습니다. SOLID 이해는 디자인 패턴 학습과 활용에 큰 도움이 됩니다.
이상으로 Swift에서의 SOLID에 대해 알아보았습니다. 코드를 작성할 때 SOLID 원칙을 항상 되새기며 더 나은 객체지향 설계를 해 나가시기 바랍니다.