인프런 커뮤니티 질문&답변
작성한 질문수
[#다시질문] Person과 Product 관계
작성
·
129
0
안녕하세요, 타입스크립트에서 타입호환 부분에 대해 질문 요청드립니다.
여기 올라온 질문 중 "Person과 Product 관계"라는 글이 있었는데요, 저 역시 궁금한 부분이라,
공부를 하면서 '이렇게 생각하는게 맞는가?' 고민이 있습니다.
제가 정리한 내용이 맞는지 피드백을 받고 싶어 문의 드립니다.
(*=> 이란 기호는 단락 구분이 에디터에서 적용이 안되서 구분 용도로 추가했습니다)
=>
"추가 속성이 있으면 값의 집합은 더 작아진다"
"유니온 타입이 있으면 값의 집합은 더 커진다."
"추가 속성이 있으면 값의 집합은 작아지므로..."
"속성 타입의 범위가 넓어지면 값의 집합은 커진다."
"1.구체적(?)으로 변하기 때문에 속성값이 없는 쪽이 더 많은 값을 할당 받을 수 있다고 생각해도 될까요 ? " ,Person과 Product의 관계 질문 중,
(*관련부분, 책 실전리액트 프로그래밍 리액트훅에서 부터 Next.js까지 중 p461~p462,
선택 속성이 타입호환성에 미치는 영향,
추가 속성과 유니온 타입이 타입 호환성에 미치는 영향 내용에서)
=>
타입스크립트는 구조적 타이핑으로,
인터페이스든 클래스든, 커스텀 type으로 정의한 무엇이든,
해당 묶음이 갖고 있는 속성들/프로퍼티들이 서로 일치 한다면(서로 보유하고 있다면) 필수적으로 갖는 속성을 나도 갖고 있다면,,
키워드(인터페이스든 클래스든, 커스텀 type) 여하에 상관없이 서로 타입을 호환할 수 있다고 이해했습니다.
=>
집합의 "크기"라고 하는 것을 속성(프로퍼티)의 갯수가 많고 적음에 연관되어 있다고 생각하는데요,
속성(프로퍼티) 갯수가 많을 수록 값의 집합이 작아진다는 의미는 다음과 같다고 생각합니다.
=>
우선 해당 타입을 호환을 하려면,
구조적 서브타이핑 원칙상. 보유한 속성(프로퍼티)를 모두 혹은 필수적으로 어느정도는 일치해야하는데,
저는 이런 일치해야하는 조건들이 속성들의 갯수가 많아지면 많아질 수록 최소한 보유한 프로퍼티들을, 갯수를 만족해야합니다,
=>
막상 그 많은 속성들을 가진 타입을 찾기 어려워서,
만족할 수 없어서,
조건에 부합되는 경우가 적어서
값의 집합이 작아지는거 아닐까 라고 생각합니다.
=>
반대로,
속성(프로퍼티)의 수가 적은 경우, 적은 속성(프로퍼티)만 가지거나 만족하면 되기 때문에,
=>
전자는, 부합하는 경우의 수가 적어서 "값의 집합이 적다" 고 하는 것이고
후자는, 부합하는 경우의 수가 훨씬 많아서 "값의 집합이 크다" 라고 이해를 했습니다.
=>
소개팅으로 비유하자면,
남녀 각자가 서로 보유한 조건(속성/프로퍼티)이 많을 수록 / 적을 수록,
이에 부합할 경우의 남자/여자의 수가 적을 수도/많을 수도 있는데 (집합이 작거나/커질 수 있는데) ,
조건이 많다면, 최소한 조건은 만족해야 하니 이에 부합할 남자/여자를 찾기 어렵겠죠,,,
(타입이 구체적일 수록, 속성의 갯수가 많을 수록, 이를 호환할 타입의 수가 적어서 집합의 크키가 작아진다)
=>
반대면 찾기 쉬워지겠죠,
즉, 속성의 갯수가 많을 수록,
이 속성들의 갯수를 만족할 만한 타입이 없기 때문에, 타입이 구체적일 수록, 더욱 집합의 크키가 줄어들고,
반대로 타입이 가벼워?질수록,
즉 요구하는 프로퍼티의 숫자가 적다면, 더욱 집합의 크기가 커지는 그런거 라고 생각하는데요, 하는거라고
=>
속성관점에서 보면,
속성 타입의 범위가 넓어지면(예:number | string) number 도 받을 수 있고 string 도 받을 수 있어서,
그만큼 영역이 커지기 때문에 값의 집합이 커진다는 의미가 아닐까요,,
=>
타입스크립트 에 대해서 왜 그런지 자세하게 참고할 블로그가 적어서요
혼자 나름의 정리를 하면서 고군분투 중인데, 짧은 답변이라도 큰 힘이 됩니다.
=>
감사합니다!
=>
[에디터에서 줄바꿈 간격을 아무리 넣어도 안되네요..;;;
더구나 장문에 글이라,,,죄송합니다.
아무리 수정해도 단락이 나뉘어지지 않네요...;;.]
답변 1
0
이재승
지식공유자
안녕하세요
> 구체적(?)으로 변하기 때문에 속성값이 없는 쪽이 더 많은 값을 할당 받을 수 있다고 생각해도 될까요?
네 맞습니다
그리고 전체적으로 이해하신 내용이 맞습니다
이재승
지식공유자
말씀하신대로
속성 갯수가 많아질 수록 => 값의 집합이 작아진다 => 할당 받기 어려워진다
라고 이해하시면 될 것 같아요
개별 속성의 타입은 각 속성 별로 위에 말씀하신 내용을 똑같이 적용하게 됩니다
속성의 타입이 또 다시 interface 로 정의된 타입일 수도 있으니까요 (함수 타입을 수도 있고, number 일 수도 있겠죠)
만약 속성의 타입이 any 라면 무엇이든 받을 수 있으니 값의 집합이 (다른 타입에 비해) 커진다고 생각할 수 있습니다
안녕하세요, 글 읽어주시고 답변 남겨주셔서 진심으로 감사드립니다.
아마도, 남겨주신 답변 처럼 이해하고 있는 듯 합니다.
그래도 조금은 제가 제대로 이해하고 있는지 걱정?이 들어,
다시한번 답변에, "=>" 이후의 내용으로 정리해봤는데, 제대로 이해했을까요,
혹여 저와 같은 고민/물음이 있는 분들을 생각하고 염두해 작성한 글이라,
조금은 자세하고 길어지게 됐습니다.
완벽하지는 않지만, 어느정도는 이해하고 있다고 확인 받게 된다면,
이전보다 조금은 다르게 타입스크립트를 생각하며, 공부 할 수 있을 것 같습니다.
감사합니다:]
> 구체적(?)으로 변하기 때문에 속성값이 없는 쪽이 더 많은 값을 할당 받을 수 있다고 생각해도 될까요
: 구체적(?)으로 변하기 때문에
=> 저는 "구체적"이라는 단어가 내포한 의미는 (인터페이스든, 커스텀 type든 이것이 보유한/이것에 정의된) 프로퍼티가 많아지는 것, 혹은 프로퍼티가 많이 정의된 "상태" 라고 이해하고 있는데요,
구체적이라는 건, 프로퍼티의 갯수가 많아져 프로퍼티로 빽빽히? 차 있는 이미지로 그려집니다.
갯수적인 조건도 있겠지만,
프로퍼티가 갖는 타입이 "string"같은 단일 타입 집합, "string|number"같은 복합 타입집합, 타입집합이 다른 타입을 포함할 수 있는지에 대한 고민도 있을 것이라 생각합니다.
아무튼, 속성의 갯수의 문제든, 속성이 가진 타입간의 관계든,
우선, 구체적으로 변한 타입들은 속성의 갯수가 많은데, 이를 호환하려면,(프로퍼티의 갯수든, 프로퍼티가 갖는 타입들간의 관계든 )
(호환하려는) 그 상대 타입도 최소한 이런 구체적인 조건들을 충족해야 하는 것으로 이해했습니다.(타입스크립트는 구조타이핑 때문에 이렇다고 이해했습니다.)
그래서 상대 타입은 조금 부담?스러울 것 같습니다.,,
왜냐하면 호환하고 싶은 타입이 너무 구체적이고, 타입집합 관점에서 (너무) 촘촘?하다면,
갯수적인 문제나, 타입집합을 포함할 집합인지 체크하는 등, 이를 만족할 타입은 찾기 어렵거나, 아예 없을 수도 있기 때문이죠
이런 이유로, 구체적인 타입에 호환되는 경우가 적기 때문에(찾기 어렵기 때문에),
: 속성값이 없는 쪽이
=> 상대적으로 속성의 갯수가 적은 타입일 경우,
호환하려는 타입은 자신이 (호환하기 위해) 가져야 할 속성의 수가 적기 때문에,
즉, 조건이 쉽고, 허들이 낮기 때문에
속성값이 없는 쪽이 더
: 더 많은 값을 할당 받을 수 있다
=> (구체적인 곳(속성이 많이 정의된 타입)보다는)
상대적으로 더 많은 값(타입, 프로퍼티가 있는 인터페이스 혹은 커스텀 type)을 할당 받을 수 있다,
라고 이해했습니다.