463 타입으로 견고하게 다형성으로 유연하게 3장 총 73페이지 2025 02 07 #465
Conversation
…Conference into 453-타입으로-견고하게-다형성으로-유연하게-2장-총-79페이지-2025-01-24
jongfeel
requested review from
wooyaggo86,
TaeHyoungKwon,
jintaeyeong,
hemil0102,
ymkim97,
aquamagic9,
fkdl0048,
tttghost and
dhlee3994
|
우측에 있는 |
jongfeel
changed the base branch from
main
to
453-타입으로-견고하게-다형성으로-유연하게-2장-총-79페이지-2025-01-24
jongfeel
changed the base branch from
453-타입으로-견고하게-다형성으로-유연하게-2장-총-79페이지-2025-01-24
to
main
| 1. 평소에 잘 알고 쓰고 있는 제네릭에 대해 자세한 설명을 보고 이해할 수 있던 시간이었습니다. | ||
| 제 경험적으로 처음부터 제네릭으로 만들어 두면 좋겠지 혹은 나중에 쓰겠지 하고 만들었던 클래스와 메서드들은 | ||
| 거의 재사용되지 않거나 만든게 의미가 없을 정도로 하나의 타입만 사용했던 적이 많이 있었습니다. | ||
| 그래서 지금은 일부러 제네릭 타입을 만들거나 하지 않고, 필요할 때 만드는 쪽을 선택하는 편입니다. | ||
| 제네릭 타입에 대해 설계 할 때 부터 필요할 거라 생각하고 만들었는데 만들고 나서 쓸모가 없어지거나 괜히 만들었다는 때가 있었는지 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
개인적으로는 파이썬을 사용하면서, 제네릭 도입에 대해서 고민해본적은 없었던 것 같아서 논의 내용에 완전 매칭되는 답변은 불가할 것 같습니다(파이썬에서도 type hint로 제네릭을 사용할 수 있음)
다만, 제네릭은 아니지만, 필요할 거라 생각하고 만들었는데, 이후 쓸모 없어지는 경우는 코드레벨에서도, 코드레벨이 아닌 경우에서도 자주 겪는 것 같습니다
코드레벨에서는 확장성을 고려해서, 인터페이스를 사용했지만, 구현체가 1개만 만들어지고 더 안만들어지는 경우, 전략패턴을 적용해두었는데, 막상 정책 변경으로 전략객체를 굳이 더 만들일이 없을 때 등
코드레벨이 아닌 경우는, 마이크로서비스 설계 시, common 한 기능의 경우에 전사에서 사용할 수 있도록 설계를 요청 받는 경우가 있는데, 이를 고려해서 설계해서 개발했으나, 실제로는 전사 MS 중에 사용 비율이 매우 낮을 때 등
| 1. 평소에 잘 알고 쓰고 있는 제네릭에 대해 자세한 설명을 보고 이해할 수 있던 시간이었습니다. | ||
| 제 경험적으로 처음부터 제네릭으로 만들어 두면 좋겠지 혹은 나중에 쓰겠지 하고 만들었던 클래스와 메서드들은 | ||
| 거의 재사용되지 않거나 만든게 의미가 없을 정도로 하나의 타입만 사용했던 적이 많이 있었습니다. | ||
| 그래서 지금은 일부러 제네릭 타입을 만들거나 하지 않고, 필요할 때 만드는 쪽을 선택하는 편입니다. | ||
| 제네릭 타입에 대해 설계 할 때 부터 필요할 거라 생각하고 만들었는데 만들고 나서 쓸모가 없어지거나 괜히 만들었다는 때가 있었는지 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
저는 제네릭 타입을 직접 만들어서 사용한 적은 없는 것 같습니다. 다만 설계 당시에 필요성을 느끼는 부분에 대해서는 제네릭을 활용하면 좋을 것 같습니다.
멘토님이 별로 좋아하시지 않는 싱글톤의 경우 Unity 게임 개발의 경우 대부분 제네릭을 활용하여 제작하다 보니 다른 Unity 깃허브를 봐도 대부분이 표준적으로 사용하는 코드가 있긴 합니다. 비슷하게 UI관련 코드도 제네릭으로 만들어지는 경우도 종종 본 것 같습니다.
개인적으로는 인터페이스보다 좀 더 제약이 강하고 사용하기 어려운 감이 있어서 제네릭보단 인터페이스를 주로 활용하려고 합니다. 이번에 책을 읽고 나서는 좀 더 활용해보자는 생각이 듭니다.
| 2. 제네릭 타입의 메서드나 클래스를 만들면서 곤란했던 적이 있었는지 얘기해 보면 어떨까 합니다. | ||
| 저는 T 타입이 클래스 타입인걸 고려해서 생성하려고 할 때가 있었는데 new T()와 같은 코드를 사용할 수 없어서 한참 찾아봤다가 | ||
| 겨우 T 타입 객체를 생성하는 방법을 찾아서 적용했던 적이 있었습니다. | ||
| (최근은 아니고 10년도 훨씬 넘은 얘기입니다.) | ||
| 저와 다르게 제네릭 타입을 정의하고 코드를 작성하면서 어려웠던 부분이 있다면 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
저는 제네릭 자체를 많이 활용해보지 않아서 (대부분 사용하는 입장) 작성 당시에 어색했던 기억은 있습니다. 다만 다른 코드를 볼 때 where키워드가 매우 길거나 깊이가 길게 연결되어 있는 코드를 보고 어려워했던 기억이 있습니다!
| 1. 평소에 잘 알고 쓰고 있는 제네릭에 대해 자세한 설명을 보고 이해할 수 있던 시간이었습니다. | ||
| 제 경험적으로 처음부터 제네릭으로 만들어 두면 좋겠지 혹은 나중에 쓰겠지 하고 만들었던 클래스와 메서드들은 | ||
| 거의 재사용되지 않거나 만든게 의미가 없을 정도로 하나의 타입만 사용했던 적이 많이 있었습니다. | ||
| 그래서 지금은 일부러 제네릭 타입을 만들거나 하지 않고, 필요할 때 만드는 쪽을 선택하는 편입니다. | ||
| 제네릭 타입에 대해 설계 할 때 부터 필요할 거라 생각하고 만들었는데 만들고 나서 쓸모가 없어지거나 괜히 만들었다는 때가 있었는지 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
제네릭을 실제 사용한 경우는 다양한 타입에 대해서 print를 할 경우 제네릭 함수로 만들어 보았습니다. 이 같은 경우도 다양한 타입에 대해 언젠가 사용할 경우가 있겠지라고 생각하고 만들어 둔 경우인 것 같습니다.
제네릭을 만들고도 실제로 다양한 타입에 대해 사용하지 못할 경우도 있기 때문에 말씀하신 것처럼 정말 필요한 경우가 생겼을 때 제네릭으로 수정하는 방법도 좋을 것 같습니다.
3장에서 무엇이든 타입(universally quantified type)과 무엇인가 타입(existentially quantified type)이 조금 이해하기 어려웠던 부분이었던 것 같습니다.
저자가 처음에 얘기한 대로 이걸 쓸 일이 있을까? 를 의심하면서 읽긴 했는데
두 번 다시 읽어 보고 조금 이해를 했던 것 같습니다.
예제 언어는 스칼라와 하스켈이었지만 C#이나 Java로도 각각 제네릭 클래스 타입, 제네릭 인터페이스 타입으로 정의하면 만들 수 있지 않을까 라는 생각도 들었습니다.