상위 엔티티에 클래스 제네릭 타입파라미터 적용에 관한 질문입니다.

Question

하도 애러를 마주하다 보니 잠재적인 오류가 나면 어쩌나 하는 불안감이 돕니다 애러가 안나니까 불안합니다.BaseEntity 를 확장한 SubEntity 를 활용하는 형태로 만들다 보니 초반에는 첫째와 같이 타입파라미터는 `BaseEntity 를 확장한다` 는 단순한 논리로 구성했다가, 와일드 카드를 써야 안전하다는 것을 알게되서 일단 둘째 처럼 적용해 본 결과, 컴파일은 성공하였습니다.그러나, 잠제적인 문제나 주의사항 등을 알지 못합니다. public abstract class BaseEntity>public abstract class BaseEntity>> 그리고, 위의 2 코드의 차이를 설명하려니, 설명이 잘 안됩니다. 첫째는 `BaseEntity 를 확장하고, BaseEntity 타입파라미터는 BaseEntity의 Sub 클래스 이다` 는 의미로 작성했는데 둘째는 `BaseEntity 를 확장하고, BaseEntity 타입파라미터 는 BaseEntity 를 확장한 아무거나????` 라는 의미로 해석을 일단 했지만, 논리적으로는 다를게 없어서 혼란스럽네요..T extends BaseEntity 와T extends BaseEntity> 는 다른겁니까? 사용상의 발생 문제도 궁금합니다. 예를 들면, 이건 이게 되는데, 이건 안되지만 둘째는 이건 된다 같은 예시가 궁금합니다이것에 대해서 조언을 구합니다 읽어주셔서 감사드립니다.

포기해.. · Accepted Answer

public int calSum(List list) { int sum = 0; for (Number i : list) { sum += i.doubleValue(); } return sum;}위와 같은 함수가 있다고 가정했을 경우에List int_list = new ArrayList();List double_list = new ArrayList();List string_list = new ArrayList();calSum 이라는 함수는 Number하위객채로된 list만 받겠다는 것이고 String형 string_list는 못 넣겠죠calSum(int_list); <-- 정상calSum(double_list); <-- 정상calSum(string_list); <-- 오류 List objList = new ArrayList();calSum(objList); <-- 정상(오류는 아니지만 eclipse 경고표시뜸)calSum((List) objList); <-- 정상 이것 처럼 제네릭을 사용하지 않은 변수도 넣을 수 있습니다. 는 타입을 고정시킨 것이고는 타입을 받는 시점에 판단하겠다는 얘기죠. 제네릭 사용 잘 안합니다. 참고용으로 알아 두세요.보통 받는 형식을 고정시켜서 코딩시에 잘못된 변수를 할당했을 경우에 바로 오류표시를내보이게해서 실수를 줄이기 위해 사용한다 정도겠죠?

Truestar · Answer

포기해.. 님 명쾌한 답변 감사드립니다. 고구마 먹다 스프라이트 먹은거 같네요 후련합니다. 단지 말씀해 주신 부분에 궁금증이 생겼는데요, &#96;제네릭이 사용이 안되고 있다&#96; 라는 것은, 어떤 이유로 인해 그런걸까요..? 클래스 재활용적인 면에서는 압도적이라 판단이 되긴 합니다만, 요즘 리엑티브 프로그래밍, 함수형 같은 페러다임의 변화가 원인일까요? 막연한 궁금증으로 추측해봤습니다. 읽어주셔서 감사합니다.

포기해.. · Answer

왜 사용이 잘 안되는지는 관심이 없어서 모르겠습니다. 제가 사용하지 않는 이유는 변수의 타입을 고정시켜서 함수의 확장성을 저하시키기 때문에 안씁니다.javascript 처럼 어떤 형태의 변수건 받아서 함수 내부에서 알아서 처리해서 코딩시에 최대한 간결하게 쓰는게 가독성이 좋고 효율적이라서 입니다

Truestar · Answer

답글 감사합니다.&#34;제네릭 사용 잘 안합니다. 참고용으로 알아 두세요.&#34; 라고 말씀하셔서 어디서 어떻게 사용을 안하는지가 궁금했지만, 이 부분 때문에 수소문을 했으나, 포기해 님의 개인적 취향으로 여겨서 저는 동의하지 않기로 했습니다.타입 유효성 체크를 안하신다는 말씀이시면, 타입채크 반도체를 머리에 심지 않고서야 가능한 일일지 모르겠습니다... 런타임 시에 타입에 관한 모든 애러를 머리속으로 파악하고 계시는건데..말씀대로 그러시면 정말 대단하시네요그리고, 제네릭 메서드의 경우는 짧은 생각이지만, 오히려.. 확장성을 높혀주는게 맞는거 아닌가요?? 재활용을 하는데 확장성이 낮다는게 이해가 안됩니다. 가독성 면에서도, 당연히 재활용으로 인해 코드량이 줄어 가독성도 좋아질꺼라 생각이 드는데요..혹시 제가 놓치고 있는게 있을까요?

포기해.. · Answer

개발 12년차이고 여태까지 제가 본 프레임워크만 20여가지가 됩니다. 그 중에 제네릭을 사용율을 생각해 보면 20%정도 입니다. (제대로 기억은 안납니다.)아예 안쓰는 곳은 없습니다. 개발자의 개발특성에 따라서 사용하고 안하고 합니다.물론 제가 간 곳들만 유독 사용을 안했을 경우도 있습니다.저 같은 경우에는 아예 안씁니다. 확장성 같은 경우에는 java에서의 확장성의 개념과 개발에서의 확장성의 개념이 다릅니다.저는 java개발자가 아니라 공통개발자 였습니다. (물론 주언어는 java입니다.) 공통모듈개발을 할 경우에 여러 업무에서 들어오는 변수들을 받아서처리하는 공통함수를 생성해서 사용하는데일이라는게 한 업체에서 진행하는게 아니라 여러업체들이 같이 들어와 진행을 합니다.모든 업무 화면의 데이타 타입이 다 같을 수 없습니다. 확장성(개발관점)이란게 변화에 얼마나 적응을 하느냐 입니다.한 함수로 변수의 모든 변수를 포용할 수 있는 한가지 함수를 사용하느냐 변수 타입별로 동일한 이름의 함수를 여러개 만들어 사용하느냐 (오버로딩) 겠죠.이건 하나의 예시일 뿐입니다. 그리고 현실과 이론은 양립하지 않습니다.이론적으로 맞다라고 해봤자 현실에서 사용되지 않는다면 사장되겠죠. 제 말이 맞다는게 아닙니다. 굳이 제 사고방식을 이해하려고 하지 마세요.&#34;왜 사용이 잘 안되는지는 관심이 없어서 모르겠습니다.&#34; <-- 이미 말했다시피 제말은 정답이 아닙니다. 저는 뭐가 맞는지 관심이 없습니다. 저는 개발이 싫습니다.저한테서 정답을 원하지 마시고 그냥 이런 사람도 있구나 하고 넘어가세요

Truestar · Answer

그렇군요.. 저는 공통모듈 로 프레임 웍을 만들어 보자는게 저의 목표였고, 그러다보니, 반대되는 말씀에 의문점이 들더라구요,말씀을 읽어보다 보니, 상황에 따라 만들어 놓은 공통모듈에 변경이 생기면 죄다 없애고, 갈아엎는거나 다시 만들 상황이 생길 수 있기 때문에 안쓰는 기술이 애시당초 모듈 내부에 들어올 수 없다는 것으로 이해를 했습니다.그렇게 될 경우에는 공통 모듈이 공통이 아닌게 되버리겠네요. 공통모듈을 갈아 엎거나, 갑 또는 동급, 을 사에 맞는 맞춤형 공통모듈이란것도 생기기도 하겠네요..? 말씀을 듣다보니, 공통모듈을 만든다는게 항상 공통이 될 수 없다는 것을 염두해야 되것 같습니다. 솔직히 제가 공통 모듈에 관여하는 분에게 접해 들을 정보나 대화에 기회가 없다보니 이렇게 물어보게 된 것 같습니다. 답변 감사합니다. 많은 도움이 되었습니다.

상위 엔티티에 클래스 제네릭 타입파라미터 적용에 관한 질문입니다.

6개의 답변

#generic 목록