안녕하세요.
근래 Method 만들때 리턴형식을 튜플로 만들어 보고 있는데
개발시 이점이 좋아서 튜플 형태로 만들어 갈려고하는데 괜찮을까요?
4개의 좋아요
낮은 버전의 닷넷 코어, 닷넷 프레임워크로 클래스 라이브러리를 내보낼 일이 있거나, 다른 프로그래밍 언어 (예: VB.NET, C++/CLI)와 상호작용하는 코드를 만드신다면, 잘 작동하는지 호환성을 확인해보는 과정을 추가하시면 어떨까 싶습니다.
그리고 내보내야 할 타입의 수가 많다면, 유지보수 문제를 피하기 위해 별도의 데이터 클래스 타입을 두시는 것도 좋을 것 같습니다.
4개의 좋아요
반환형으로 튜플(ValueTuple 포함)을 적극적으로 코딩에 사용해본 경험으로 말씀드리면, 외부로(public) 공개되는 메소드 반환형으로는 지양해야 한다는 결론입니다. 기억의 강을 건너거나, 메소드를 사용하는 코드가 많아지면 많아질 수록 컨트롤이 안됩니다.
내부용(private) 메소드 또는 로컬 메소드 반환형으로는 불필요한 클래스 또는 구조체를 만들지 않아도 되어 의미 있었습니다.
2개의 좋아요
반환타입이 동일형식이 많은 클래스로 사용하고 그외 경우는 튜플을 사용하는게 적절할까요?
1개의 좋아요
사실 빠르게 코드를 전개할 때 튜플이 유용하긴 한데 결국엔 지역적(locally)으로 사용해야 할 것 같습니다. @rkttu 님이 잘 말씀 주신 것 처럼 외부로 노출되는 경우 Tuple의 값이 Item1, Item2으로 노출이 되고 또 사용 튜플 유형을 다시 정의해야 하는 등 장점보다 단점이 많아집니다. 그렇기 때문에 강력히 사용을 지양해야 한다고 저도 생각하고요, ValueTuple의 경우 하위 호환성을 살펴봐야 합니다.
저는 동일형식이 많고 적고의 기준 보다는 얼마나 지역적이냐로 판단하는게 맞다고 생각합니다.
5개의 좋아요
괜찮냐의 기준이 동작만 하면 되냐고 하시면 괜찮습니다.
하지만 튜플을 사용하면 ide에서 개발할때도 별칭을 안써주면 뭐하는 코드인지 못알아먹게 되고 별칭을 쓴다해도 Json Serialize나 리플랙션등을 사용한다면 코드에 사용한 별칭이 이름이 실제로는 Item1, Item2로 치환되기 때문에 역시 좋지 않습니다. 인터페이스나 확장함수등에 대한 정의가 불가능해서 기초수준의 문법만 사용할 수 있습니다. 코드가 사용된 참조를 찾을때도 튜플로 해버리면 해당 객체가 어디서 사용되는지도 제대로 탐색하지 못하기 때문에 IDE의 서포트도 제대로 받기 어렵습니다.
public 하게 노출되는 인터페이스가 튜플인건 좋지않아보이네요.
4개의 좋아요
저 역시 윗분들과 같이 public에서는 사용하지 않는 것이 좋을 것 같아요.
3개의 좋아요
값의 액세스를 모델 클래스 처럼 네이밍 방식으로(예:tpl.Name, tpl.UserId) 액세스 할 수 있는
경우라면 써볼만 하다고 저는 생각 됩니다만, 튜플의 기본적인 액세스 방식인 순차적으로 셋팅 된 값을 (예:tpl.Item1 ~ Item{n}) 리턴하도록 하신다면 시인성이 좋지 않아 쉽게 값의 의미를 유추하기가 어렵기 때문에 순차적 액세스 방식의 튜플은 프로젝트에 적용하시지 않는 것을 추천드립니다.
2개의 좋아요
대부분 같은 의견이시군요. 저도 그러합니당…~ㅂ~
근데 말이죠.
제 생각엔 이거 약간 정적 언어에 익숙함이 한 몫하고 있는 게 아닐까 하는 생각도 살짝드는데요.
비구조화 할당을 밥 먹듯이 쓰는 동적언어(javascript 같은?) 개발자들은
이걸 불편하다고 못 느끼는 거 같은데…
이건 우리들만의 패시브 일까여?ㅅ?
2개의 좋아요