Typescript: Union 형식, Intersection 형식, 상속
이 글에선 Typescript에서 사용되는 형식인 Union 형식, Intersection 형식에 대해서 알아보고,
필자가 가졌던 의문인 Union형식을 사용할거면, 상속을 사용하는 것이 낫지 않은가? 에 대해 설명을 하고,
Union 형식이 사용되는 간단한 예시를 소개할 예정이다.
Union형식과 Intersection형식
Union 형식
Union 형식은 여러 타입 중 하나의 타입을 가질 수 있도록 정의한다. 이는 상속의 개념에서 부모 클래스와 비슷하게 동작한다. | 연산자를 사용해 여러 타입을 조합할 수 있다.
예를 들어, Circle과 Rectangle을 대표하는 Shape 타입을 Union 형식으로 정의할 수 있다.
type Circle = {
radius: number;
};
type Rectangle = {
x: number;
y: number;
};
type Shape = Circle | Rectangle;
function area(shape: Shape) {
// 계산..
}
위와 같은 상황 뿐만 아니라 아래처럼 기본형으로도 유니온형식을 만들 수 있다.
function foo(bar: number | string){
//
}
kind 속성
위처럼 구현하게 되면, 좋다 부모클래스를 만든것 까지는 좋다 하지만, area 내부에서 대체 이들을 어떻게 구별할 것인가? 위의 예제에서는 Circle과 Rectangle 구분하기 쉽기 때문에 아래와 같이 구분할 수 있다.
function area(shape: Shape){
if("radius" in shape) { // Circle의 경우
return Math.PI*shape.radius*shape.radius;
} else { // 나머지 즉 Rectangle의 경우
return shape.x*shape.y;
}
}
하지만 유니온 형식에 포함되는 타입이 많아져서 프로퍼티가 구별하기 힘들정도라면? 어떻게 구별할 것인가. 그래서, kind 속성이 등장했다. 유니온형식의 요소를 구별하기 위함이다.
type Circle = {
radius: number;
kind: "circle";
};
type Rectangle = {
x: number;
y: number;
kind: "rectangle"
};
type Shape = Circle | Rectangle;
위 방식을 통해 유니온형식의 구성요소 하나하나를 구별할 수 있고, switch문을 사용해 아래와 같이 함수를 작성할 수 있다.
function area(shape: Shape){
switch (shape.kind) { // kind를 통해 구성요소를 구별
case "circle":
return Math.PI*shape.radius*shape.radius;
case "rectangle"
return shape.x*shape.y;
default:
throw Error("불가능한 방식입니다.");
}
}Intersection 형식
Intersection형식은 자식클래스를 만드는것에 비유할 수 있다. & 키워드를 통해 지정한다. 또한 예시를 통해 살펴보자
type Toy = {
price: number;
quantity: number;
};
type BoardGame = Toy & {
players: number;
};
type Puzzle = Toy & {
pieces: number;
};
vs 상속
TypeScript를 공부하며, "Union 형식을 사용할 바에 차라리 상속을 사용하는 것이 더 나은 선택이 아닐까?"라는 의문이 들었다. 하지만 Union 형식과 상속은 서로 다른 상황에서 더 적합한 방법으로 사용될 수 있다. 이를 가독성과 확장성 측면에서 비교해 보았다.
가독성
Union 형식은 코드가 간결하고 직관적이다. 특히 타입이 간단한 경우, 클래스 문법을 사용하는 것보다 가독성이 좋다.
아래 두 코드를 비교했을때 Union 형식을 사용하는 쪽이 어떤 type이 있는지, 어떤 동작을하는지 한눈에 알아보기가 쉽다. 상속을 사용하는 경우 코드의 규모가 커질수록 복잡하고 알아보기 힘들어진다.
// Union 형식
type Shape =
{kind: "circle"; radius: number} |
{kind: "rectangle"; x: number; y: number} |
{kind: "triangle"; base: number; height: number};
function area(shape: Shape){
switch (shape.kind) { // kind를 통해 구성요소를 구별
case "circle":
return Math.PI*shape.radius*shape.radius;
case "rectangle":
return shape.x*shape.y;
case "triangle":
return shape.base*shape.height/2;
default:
throw Error("불가능한 방식입니다.");
}
}// 상속
interface Shape {
area(): number;
}
class Circle implements Shape{
constructor(public radius: number){}
area(): number {
return Math.PI*this.radius*this.radius;
}
}
class Rectangle implements Shape{
constructor(public x: number; public y: number;){}
area(): number {
return this.x*this.y;
}
}
class Triangle implements Shape{
constructor(public base: number; public height: number){}
area(): number {
return this.base*this.height/2;
}
}
확장성
확장성의 면에서도 이점이 있다. type과 Union 형식은 OOP의 철학을 따르진 않지만, OCP(개방폐쇄의 원칙)을 자연스럽게 만족한다. 새로운 타입을 추가할 때 기존 코드를 수정할 필요 없이 새로운 타입만 정의하면 된다.
type Shape =
{kind: "circle"; radius: number} |
{kind: "rectangle"; x: number; y: number} |
{kind: "triangle"; base: number; height: number} |
{kind: "square"; x: number}; // 새로운 타입을 추가
function area(shape: Shape){
switch (shape.kind) { // kind를 통해 구성요소를 구별
case "circle":
return Math.PI*shape.radius*shape.radius;
case "rectangle":
return shape.x*shape.y;
case "triangle":
return shape.base*shape.height/2;
case "square": // 새로 추가된 타입에 대한 처리
return shape.x*shape.x;
default:
throw Error("불가능한 방식입니다.");
}
}
결론
Union형식은 때에 따라선 OOP를 따르지 않고 사용할 수 있는 하나의 방법이다.
- 데이터 중심적 모델, 메서드(즉, 행동)이 중점이 아닌 상황
- 그 구조가 매우 간단하여 class문법을 쓰기엔 오버헤드가 큰 상황
결론적으로, Union 형식은 OOP를 따르지 않아도 효율적이고 간단한 해결책을 제공할 수 있는 강력한 도구이다. 상황에 따라 Union 형식을 선택하면 코드의 간결성과 확장성을 모두 확보할 수 있다.
위 내용을 공부하면서 내가 너무 OOP에 갇혀있다는 생각을 했다. type과 Union을 보면서 이는 OOP의 원칙을 만족하는가 (애초에 Union은 OOP가 말하는 객체조차도 아니었지만) 와 같은 생각을 하며 계속 Union에서 OOP의 편린을 찾으려고 애를 썼다. 처음에는 심지어 Union 형식을 보며 화도 났다. 어떻게 이렇게 코드를 짤 수 있냐며. 위 내용을 공부하면서 내 갇혀있던 생각도 좀 더 넓게 생각하게 될 수 있어진 것 같다.