추상화
from 이펙티브 코틀린
안녕하세요 iOS 개발자 지니입니다 :-)
요즘 주 1회 이펙티브 코틀린 책으로 안드, iOS, 서버가 함께 스터디를 하고 있어요
사실 코틀린으로 Hello World 도 안찍어봤지만,,, ㅎㅎ
좋은 코드, 좋은 설계에 대한 관점은 어떤 언어든 동일하니까 스터디를 통해 많이 배우고 있습니다.
(Effective Swift 일본어 책이 나왔다고 들었는데, 한글판이 얼른 나오면 좋겠어요 ▼・ᴥ・▼)
이번 주는 4장 > 추상화 를 스터디하는 시간이였는데요,
책을 읽으며 추상화는 제가 생각했던 것 보다 더 넓은 개념이고 추상화를 할 수 있는 방법도 다양하다는 것을 알게 되었습니다.
좋았던 책 내용을 정리해보도록 할게요!
1. 추상화란?
컴퓨터 과학에서 추상화(abstraction)는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려내는 것을 말한다.
조금 더 간단하게 표현하면, 추상화는 복잡성을 숨기기 위해 사용되는 단순한 형식을 의미합니다.
ex 1)
대표적인 예로 인터페이스가 있습니다.
인터페이스는 클래스라는 복잡한 것에서 메서드와 프로퍼티만 추출해서 간단하게 만들었으므로,
클래스의 추상화라고 할 수 있습니다.
ex 2)
함수를 정의할때 그 구현을 함수 시그니처 뒤에 숨기게 되는 데, 이것도 추상화입니다.
ex 3)
SQL을 직접 작성하지 않고 ORM (Object Relational Mapping) 같은 DAO (Data Access Object) 활용하는 것도 추상화의 한 종류입니다.
ex 4)
많은 개발자는 프로그래밍에서 하는 모든 일이 추상화라는 것을 종종 잊어버립니다.
숫자를 입력하면 내부적으로 0과 1이라는 복잡한 형식으로 표현됩니다.
문자열을 입력하면 모든 문자가 UTF-8과 같은 복잡한 형식의 문자 집합으로 만들어집니다.
이러한 것들이 모두 추상화 되어있기 때문에 우리가 쉽게 사용할 수 있는 것입니다.
2. 추상화의 목적
추상화는 프로그래밍 세계에서 가장 중요한 개념 중 하나입니다.
OOP 에서 추상화는 세가지 주요 개념 중 하나입니다. (나머지 두 개념은 캡슐화와 상속)
함수형 프로그래밍에서는 '프로그래밍이란 추상화와 컴포지션으로 이루어지는 것' 이라고 까지 표현합니다.
그럼 추상화는 왜 중요할까요?
굉장히 잘 만들어진 인터페이스 라고 할 수 있는 자동차를 생각해봅시다.
자동차 운전자는 자동차를 조종하는 인터페이스(핸들, 페달 등)를 사용하는 방법만 알면 됩니다.
이는 자동차의 종류(가솔린 자동차, 경우 자동차, 전기 자동차 등) 과 크게 관계 없고
자동차가 내부적으로 여러 반도체와 특수한 시스템을 도입해도 자동차의 인터페이스는 거의 동일하게 유지됩니다.
추상화는 이처럼 내부적으로 일어나는 모든 것을 마법처럼 숨겨줍니다. 따라서 운전자는 자동차가 어떻게 구성되는 지 전혀 몰라도 괜찮습니다. 운전하는 방법만 알면 됩니다.
마찬가지로 자동차를 좋아하는 사람들은 자동차를 튜닝하기도 하는데, 운전에 영향을 주지 않는다면 무엇을 해도 괜찮습니다.
'추상화와 자동차' 비유를 잘 이해하면 프로그래밍에서 추상화를 사용하는 목적을 잘 이해할 수 있습니다.
프로그래밍에서는 다음과 같은 목적으로 추상화를 사용합니다.
- 복잡성을 숨기기 위해
- 코드를 체계화하기 위해
- 만드는 사람에게 변화의 자유를 주기 위해
3. 추상화를 하는 다양한 방법
책에서 추상화를 하는 몇가지 방법을 예제와 함께 설명합니다.
1. 상수로 추출한다
2. 동작을 함수로 래핑한다.
3. 함수를 클래스로 래핑한다.
4. 인터페이스 뒤에 클래스를 숨긴다.
5. 보편적인 객체(universal object)를 특수한 객체(specialistic object)로 래핑한다.
3.1 상수로 추출
숫자가 코드에 반복적으로 등장하면 상수로 추출하는 것이 좋습니다.
그러면 이름을 붙일 수 있고, 나중에 해당 값을 쉽게 변경할 수 있습니다.
AS IS
func isPasswordValid(text: String): Boolean {
if(text.length < 7) return false
...
}
TO BE
const val MIN_PASSWORD_LENGTH = 7
func isPasswordValid(text: String): Boolean {
if(text.length < MIN_PASSWORD_LENGTH) return false
...
}
3.2 동작을 함수로 래핑
토스트 메세지를 자주 출력해야한다면 간단한 확장함수를 만들어서 사용할 수 있습니다.
func Context.toast(
message: String,
duration: Int = Toast.LENGTH_LONG) {
Toast.makeText(this, message, duration).show()
}
// 사용하는 쪽
context.toast(message)
만약 토스트가 아니라 스낵바라는 다른 형태의 방식으로 메세지를 출력하도록 바꿔야한다면 어떻게 해야할까요?
다음과 같이 스낵바를 출력하는 확장함수로 바꾸고, 기존의 Context.toast() 를 Context.snackbar() 로 한꺼번에 수정하면 됩니다.
func Context.snackbar(
message: String,
duration: Int = Toast.LENGTH_LONG) {
...
}
// 사용하는 쪽
context.toast(message)
하지만 내부적으로만 사용하더라도, 함수의 이름을 직접 바꾸는 것은 위험할 수 있습니다.
다른 모듈이 이 함수에 의존하고 있다면 다른 모듈에 큰 문제가 발생할 것 입니다.
또한 함수의 이름은 한꺼번에 바꾸기 쉽지만, 파라미터는 한꺼번에 바꾸기 쉽지 않으므로 Toast.LENGTH_LONG이 계속 사용되고 있다는 문제도 있습니다.
메세지의 출력 방법이 바뀔 수 있다는 것을 알고 있다면, 이때부터 중요한 것은 메세지의 출력 방법이 아니라 사용자에게 메시지를 출력하고 싶다는 의도 자체 입니다. 따라서 메세지를 출력하는 더 추상적인 방법이 필요합니다.
토스트 출력을 토스트라는 개념과 무관한 showMessage 라는 높은 레벨의 함수로 옮겨 봅시다.
func Context.showMessage(
message: String,
duration: Int = MessageLength = MessageLenght.LONG) {
val toastDuration = when(duration) {
SHORT -> Length.LENGTH_SHORT
LONG -> Length.LENGTH_LONG
}
Toast.makeText(this, message, toastDuration).show()
}
enum class MessageLength { SHORT, LONG }
// 사용하는 쪽
context.showMessage(message)
가장 큰 변화는 이름입니다. 큰 차이가 없다고 생각할 수 있으나.. 함수는 추상화를 표현하는 수단이며, 함수 시그니처는 이 함수가 어떤 추상화를 표현하고 있는 지 알려줍니다. 따라서 의미있는 이름은 굉장히 중요합니다.
함수는 매우 단순한 추상화지만, 제한이 많습니다. 함수는 상태를 유지할 수 없고
함수 시그니처를 변경하면 프로그램 전체에 큰 영향을 줄 수 있습니다.
구현을 추상화하는 더 강력한 방법으로는 클래스가 있습니다.
3.3 함수를 클래스로 래핑
클래스는 상태를 가질 수 있으며 많은 함수를 가질 수 있기 때문에 더 강력합니다.
메세지 출력을 클래스로 추상화 해봅시다.
클래스의 상태인 context 는 기본 생성자를 통해 주입되는데,
의존성 주입 프레임워크를 사용하면 클래스의 생성을 위임할 수 도 있고
@Inject lateinit var messageDisplay: MessageDisplay
mock 객체를 활용해서 해당 클래스에 의존하는 다른 클래스의 기능을 테스트할 수 도 있습니다.
val messageDisplay: MessageDisplay = mock()
또한 메세지를 출력하는 더 다양한 종류의 메서드를 만들 수도 있습니다.
messageDisplay.setChristmasMode(true)
이처럼 클래스는 훨씬 더 많은 자유를 보장해줍니다.
하지만 이보다 더 많은 자유를 얻으려면, 더 추상적이게 만들면 됩니다. 바로 인터페이스 뒤에 클래스를 숨기는 방법입니다.
3.4 인터페이스 뒤에 클래스 숨기기
라이브러리를 만드는 사람은 내부 클래스의 가시성을 제한하고 인터페이스를 노출합니다.
그러면 사용자가 클래스를 직접 사용하지 못하므로, 라이브러리를 만드는 사람은 인터페이스만 유지한다면 별도의 걱정없이 구현을 변경할 수 있습니다.
즉, 인터페이스 뒤에 객체를 숨김으로써 실질적인 구현을 추상화하고, 사용자가 추상화된 것에만 의존하게 만듭니다.
메세지 표시 예제에 인터페이스를 도입해봅시다.
이렇게 구성하면 더 많은 자유를 얻을 수 있습니다.
이러한 클래스는 태블릿에서는 토스트를, 스마트폰에서는 스낵바를 출력하게 할 수 있습니다.
또 다른 장점은 테스트할 때 인터페이스 페이킹(faking)이 클래스 모킹(mocking) 보다 간단하므로,
별도의 모킹 라이브러리(mocking library)를 사용하지 않아도 된다는 것입니다.
val messageDisplay: MessageDisplay = TestMessageDisplay()
마지막으로 선언과 사용이 분리되어있으므로, ToastDisplay 등의 실제 클래스를 자유롭게 변경할 수 있습니다.
다만 사용 방법을 변경하려면, MessageDisplay 인터페이스를 변경하고, 이를 구현하는 모든 클래스르 변경해야합니다.
3.5 보편적인 객체를 특수한 객체로 래핑
추가적인 예제를 하나 더 살펴봅시다.
프로젝트에서 고유 ID (unique ID) 를 사용해야하는 상황입니다.
가장 간단한 방법은 어떤 정수 값을 계속 증가시키면서, 이를 ID로 활용하는 것입니다.
private var nextId: Int = 0
func getNextId(): Int = nextId++
// 사용하는 쪽
val newId = getNextId()
미래의 어느 시점에 ID를 문자열로 변경해야한다면 어떨까요? 만약 그 시점 이전에 ID가 계속 Int로 유지될 거라고 생각해서, 여러 연산들이 타입에 종속적이게 작성되었다면 어떻게 해야할까요?
이를 최대한 방지하려면, 이후에 ID 타입을 쉽게 변경할 수 있게 클래스를 사용하는 것이 좋습니다.
data class Id(private val id: Int)
private var nextId: Int = 0
func getNextId: Id = Id(nextId++)
==
지금까지 추상화를 하는 다양한 방법을 살펴보았습니다.
참고로 이를 구현할 때는 여러 도구를 활용할 수 있습니다.
- 제네릭 타입 타라미터
- 내부 클래스 추출
- 생성 제한(ex. 팩토리 함수로만 객체 생성할수있게)
등등..
4. 추상화의 장단점을 이해하고 균형찾기
추상화는 자유를 주지만, 코드를 이해하고 수정하기 어렵게 만듭니다.
3.5 예제를 보면
더 많은 추상화는 더 많은 자유를 주지만, 이를 정의하고 사용하고 이해하는 것이 조금 어려워진 것을 볼 수 있습니다.
또한 추상화는 많은 것을 숨길 수 있는 테크닉이지만, 너무 많은 것을 숨기면 결과를 이해하는 것 자체가 어려워집니다.
3.3 예제를 보면
누군가는 showMessage 함수가 아직도 토스트를 출력할 거라고 생각하고 사용할 수 있습니다. (그리고 스낵바가 출력되는 것을 보며 혼돈에 빠질 것입니다.)
또다른 누군가는 토스트 출력에 문제가 있어서 Toast.makeText 를 찾다가 시간을 보낼 수 도 있습니다. (showMessage 를 사용해서 출력되고 있으므로)
이처럼 추상화를 사용할 때 장점과 단점을 모두 이해하고 프로젝트 내에서 균형을 찾아야합니다.
극단적인 것(추상화가 너무 많거나 너무 적은 상황)은 좋지 않습니다.
다음과 같은 요소들에 따라 답은 달라질 수 있습니다.
- 팀의 크기
- 팀의 경험
- 프로젝트의 크기
- feature set
- 도메인 지식
적절한 균형을 찾는 것은 오랜 경험이 있어야할 수 있는 일입니다.
이후에 더 일반적인 매커니즘이 필요할 가능성이 있는지, 플랫폼 독집적인 메커니즘이 필요할 수 있는 지, 이러한 확률이 얼마나 되는지 등은 여러가지 경험을 해보면 어느정도 알 수 있게 됩니다.
우리는 채용 중
함께 추상화 균형을 찾아갈 동료를 기다리고 있어요 ʕ•ᴥ•ʔ
https://careers.kakao.com/jobs/P-12460?skilset=iOS
