제목 : beans에 대해...
글쓴이: 손님(guest) 2004/11/12 17:03:29 조회수:10514 줄수:17 |
|
안녕하세요...^^
아직 내공이 많이 부족한 새끼 개발자입니다..
제가 현재 프로젝트를 수행 중인데요
beans의 정확한 개념을 알고 싶어서 이렇게 글을 드립니다.
제 생각에는 단순히 get,set을 포함한다구해서 bean이라고 생각하지 않습니다.
jsp와 bean을 사용한 프로젝트라 소개하려면 bean을 효율적으로 사용해야만 한다고
생각되기 때문입니다.
제가 생각하기에 get,set을 포함하는 것은 jsp에서 데이터를 효율적으로 넣고 빼기
위해서라 생각했습니다. 즉 bean.getXXX()라는 식이 아닌 getProperty등의 태그를
사용하여 데이터를 관리하는 것이지요...
위와 같은 의문을 가진 것은 제 옆자리에 있는 개발자가 꼭 get, set을 써야 하
냐구 물어보더라구요...
힘들게...
그러면서 자신은 변수 선언시 public으로 선언해서 사용했고 get, set은 안썼다구
하면서 그걸 보고 다른 사람들도 자신과 동일한 방법으로 코딩을 하더라구 해서요..
그럼...좋은 답변 부탁드립니다...^^
|
제목 : Re: 지길건 지켜야죠 ㅎㅎ
글쓴이: 이희승(anoripi) 2004/11/15 00:55:23 조회수:1463 줄수:20 |
|
바로 퍼블릭 필드를 쓰는 것은 일단 자바빈즈 표준에 어긋납니다. 표준은 개발자들간의
약속이니 지켜야 한다고 생각합니다. 요즘은 자동 생성도 해주니 귀찮지도 않구요.
또 요즘 Byte Code Engineering 을 하는 라이브러리들이 많습니다. 즉 getter/setter
메소드가 호출 될 때 데코레이션을 해서 특정 오퍼레이선 (e.g. validation) 이 수행되
도록 한다는 이야기지요. 또 BCE 안한다 해도 밸리데이션이나, 프로퍼티 A 가 바뀌면
프로퍼티 B 가 바뀐다던지 하는 경우도 있고요.
get/setProperty(String propName [, Object value]) 를 이용한 빈은 보통
DynaBean 이라 부릅니다. 표준은 아니고 Commons-beanutils 에서 나온 용어입니다.
스트러츠에도 있죠? 나쁜 방법이라고 말할 수는 없겠지만 프로퍼티 명을 문자열로
줘야 하니 컴파일타임에서 제대로 컴파일된 코드가 런타임에서 철자가 틀린다던지
해서 오동작할 수 있는 문제가 있어서 저는 기피합니다. 한다면 인터페이스를 만들고
다이나믹프록시로 연결해 주겠습니다. 예전에 사용해 보았는데 괜찮더군요.
--
what we call human nature in actually is human habit.
--
http://gleamynode.net/
|
제목 : Re: 자바빈즈..
글쓴이: 박영록(poci) 2004/11/15 22:54:02 조회수:3757 줄수:34 |
|
자바빈즈는 표준이라기보다 관습이죠. 전 개인적으로 악습이라고까지 보고 있습니다.
private 필드와 public getter setter의 결합은 public 필드에 비해 훨씬 많은 코드를
필요로 하고 사용하기도 훨씬 불편하지만 이런 단점을 상쇄할 만한 장점을 제공하지 않습니다.
코드 자동 생성은 편리해보이지만 코드 자동 생성의 필요성이 느껴진다는 것은 디자인에
결함이 있다는 반증일수도 있습니다. http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
좀더 실용적으로 생각할 필요가 있는 듯 합니다. 프로그래머가 코딩하면서 뭔가 불편함을
느낀다면 그것은 문제가 있다는 증거일 수 있습니다. iBatis, Spring Framework의 JdbcTemplate
등의 API가 점점 자바빈즈보다 Map에 대한 지원을 강화하고 있는 것도 beans의 불편함에
대해 느끼는 사람이 많기 때문입니다.
field encapsulation의 입장에서도 getter와 setter가 짝을 이루어 존재하는 것은 좋지
않습니다. setter로 해야하는 일이 있다면 생성자에서 하는 것이 좋죠. Data Transfer
Object로서의 자바빈즈라면 public field나 Map이 더 낫고 그 외의 경우라면 적절한
getter만 있는 immutable에 가까운 디자인이 더 낫다고 봅니다.
파이썬이나 그루비 등의 언어에는 public, private와 같은 접근 제한자가 없습니다.
객체의 필드는 직접 접근할 수도 있고 자바의 map과 유사한 방식으로 접근할 수도 있죠.
이 방식은 코딩 방식에 대단한 유연성을 가져다줍니다. field encapsulation을 강제해봐야
어차피 getter setter 주면 다 쓸 건데 굳이 문법으로 제약해봐야 실익이 없다는 생각인거죠.
다음 링크에서 이와 유사한 논의를 보실 수 있습니다.
http://c2.com/cgi/wiki?BeansConsideredHarmful
다음은 주로 setter에 대한 경계를 담고 있는 글입니다.
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox-p2.html
덧붙여, jsp:setProperty, jsp:getProperty 등의 태그는 권장하지 않습니다. JSTL을
쓰시는 게 훨씬 더 편리하고 강력합니다. 빈즈도, 컬렉션도 다 지원합니다.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀
|
제목 : Re: 자바빈즈..
글쓴이: 이희승(anoripi) 2004/11/16 08:53:37 조회수:1134 줄수:37 |
|
꼭 Setter 를 둘 필요는 없지 않나요? 자바 빈즈 스펙에서도 알 수 있지만 읽기 전용
프로퍼티의 경우 setter 가 없습니다.
Map을 DTO로 이용할 경우 Java 5 의 generics 를 사용하지 않으면 validation 을 해야 하는
문제도 있고요. Map 의 key 또는 value 가 null 인 경우도 있을 수 있고, 만약 Java 5 에서
사용되지 않은 경우에는 프로젝트으 리스크만 높이는 결과를 가져옵니다. 차라리 annotation을
이용해 getter/setter 를 자동 생성하는 게 낫지 않나요? groovy 도 그런 기능 제공한다고
하더군요.
그리고 주신 링크는 잘 읽어 보았습니다만. c2.com 에서는 바로 퍼블릭 필드를 사용하는 것이
아니라 getter 및 setter 메소드를 거치고 있어 encapsulation 의 여지를 주고 있습니다.
앨런 홀럽의 기사는 setter 를 단순히 나쁘다고 하는 것이 아니라, 이 프로퍼티한테 정말 setter
가 필요한지 잘 몰라서 무작정 setter 를 넣는 것에 대한 경계를 하라는 내용 같군요. 따라서
setter 가 나쁘다거나 퍼블릭 필드 액세스에 대한 옹호는 아니고, 따라서 적절한 부연은 아닌 것
같네요.
특히 setter 메소드가 없을 경우 bug tracability 가 현저히 떨어집니다. setter 에서
null 을 체크한다던지 하지 않고 바로 필드를 설정하게 되면 버그가 발생하는 시점과 예외가
발생하는 시점에 차이가 발생하게 되어서 추적이 생각보다 훨씬 어려워질 수도 있습니다. 단순히
스택 트레이스만 보고 버그를 찾을 수 있느냐 디버거를 돌려야 되느냐의 차이는 잘 아시리라
봅니다.
코드를 생성하는 것이 오늘날에는 툴의 역할이지만, 앞으로는 그런 것들이 컴파일타임이나
런타임에 일어나게 될 것으로 생각됩니다. 따라서 코드 상에서는 objectA.name = "A"; 라는
코드가 실제 런타임에서는 objectA.setName("A"); 로 바뀌게 되고 자동 생성된 setter 코드에는
AOP 스타일로 annotation 된 validation 이나 기타 문장이 patch 되겠죠. 즉 groovy 등의
언어에서의 = 연산자는 Java 에서처럼 단순한 대입문이 아니니 단순하게 비교하기는 힘들지
않을까 합니다.
현재 방금 말씀드린 기능이 완벽하면서도 편리하게 제공되고 있는 언어나 툴은 그다지 없는 것
같고, 다만 Java 5.0 이 발표되고 apt 라는 컴파일 툴이 함께 번들되면서 이에 대한 가능성은
한층 더 커졌다고 봅니다.
--
what we call human nature is actually human habit.
--
http://gleamynode.net/
|
제목 : Re: setter
글쓴이: 박영록(poci) 2004/11/16 12:53:53 조회수:963 줄수:53 |
|
setter에 대한 링크는 제 주장에 대한 부연이라기보다 setter에 대한 경계를 담은
링크로 소개한 것입니다. 그리고 그 링크에서도 getter & setter가 많이 나타나는
경우의 디자인 문제에 대한 언급도 하고 있죠.
빈즈를 DTO로 이용할 경우는 setter를 둘 수 밖에 없습니다. 실제적으로 DTO는
객체 처음 생성할 때 단 한 번 setting이 일어남에도 불구하고 이 때 사용하기
위해 setter를 둘 수 밖에 없죠. 객체가 커지면 모든 값을 생성자에 넘길 수도
없으니까요. 결국 나중에는 써서는 안되는 setter가 처음 생성할 때 필요하다는
이유로 만들어지기 때문에 field encapsulation을 해치게 되죠. 이것이 빈즈가
field encapsulation을 위해 public field에 대비한 불편함을 감수하면서도
정작 field encapsulation은 제대로 달성하지 못하는 이유죠.
결국 DTO는 어차피 getter & setter가 다 필요하고 DTO는 성격상 필드 내용이
자주 바뀔 수 있습니다. 런타임에 동적으로 바뀔 가능성도 있구요. 이런 점을
고려한다면 단순 Map이 빈즈보다 효율성이 높죠. 게다가 DTO가 가장 많이 사용되는
영역인 데이터베이스에서 이미 많은 툴들이 빈즈보다 Map을 바라보고 있습니다.
null 처리나 부가적인 validation도 빈즈가 낫다고 할 수 없습니다. 오히려 이런
부분을 자동화하기는 Map이 훨씬 쉽습니다. 빈즈의 경우 getter나 setter에
일일이 코딩을 하고 만약 모든 필드를 다 검사해야하거나 내용을 로그로 찍고
싶다면 리플렉션을 써야하는데 Map은 훨씬 가볍게 처리할 수 있죠. Map을 상속해서
이런 것들이 자동으로 일어나게 할 수도 있구요.
bug tracablility가 떨어질 수 있다는 가능성이 있는 것은 맞습니다. 하지만,
우선 제 경험상으로는 map으로 인해 버그 추적이 힘들어지는 경우는 거의 없었습니다.
그리고 사실 이런 문제의 추적은 테스트로 충분히 커버가 가능합니다. 실제로
map으로 인한 유연성과 생산성 증가를 비교해본다면 이 부분의 단점은 그리
중요한 문제가 아니라고 봅니다.
코드 생성이 컴파일 타임이나 런타임에서 지원된다면 부가적인 툴을 쓰는 것보다
분명 훨씬 좋겠죠. 그러나, 여전히 자동으로 생성할 수 있는 코드라면 왜
일부러 생성해야하는가 하는 고민은 해야할 것입니다.
BeansConsideredHarmful의 논의를 어떻게 보셨는지 모르겠습니다만, 거기에는
public field에 비해 빈즈가 나은 점이 별로 없다는 의견이 많죠. 이것이
public field를 쓰자는 이야기라기보다는 빈즈가 별달리 장점이 없다는 뜻으로
받아들이는 것이 좋을 듯 합니다.
저 개인적으로는 public field를 쓰는 것도 좋다고 봅니다. 예를 든 파이썬처럼
접근 제한은 걸어서 억지로 막는 것보다 API 문서, 좋은 클래스 디자인을 통해
자연스럽게 access violation이 일어나지 않게 하는 것이 좋다고 생각합니다.
전 요즘은 DTO는 거의 항상 Map을 사용하고 그 외의 경우는 setter 없이 생성자에서
파라미터를 받고 꼭 필요한 부분만 getter를 두고 있습니다. 단순히 필드 멤버를
리턴만 하는 getter도 가급적 안 만들려고 하고 있죠.
어쨋거나 개개인이 판단은 다 다를 수 있겠습니다만, 자바 빈즈가 널리 쓰인다는
이유로 그냥 받아들이기에는 해로움이 적지 않으므로 다시 한 번 검토해보는
시간이 필요할 것입니다.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀
|
제목 : Re: setter
글쓴이: 이희승(anoripi) 2004/11/16 13:17:31 조회수:1090 줄수:38 |
|
후반부에 말씀드렸듯 언어나 툴의 지원이 있다면 내부에 getter/setter 가 쓰이든 어떻든
사실은 중요한 것이 아니겠죠. 내부적으로 언어의 요소가 어떻게 구현이 되느냐는 어떻게
보면 나중의 문제니까요.
안타까운 것은 현재 그런 것이 지원되지 않는다는 것이고, 그를 어떻게 해결하느냐의 문제인데..
사실 빈즈의 방식이 100% 옳은 것이 아니라 사실상의 표준이라는 것이죠.
bug tracability 에 대해 말씀드리면.. 저 같은 경우 웹 어플리케이션 개발보다는 서버측
개발을 많이 해서 그런건지는 모르겠지만 그런 문제가 중요하게 느껴지더군요. 예를 들면,
NullPointerException은 겉에 보이는 현상이고, 어느 필드가 null 인지는 또 다른 문제죠:
String foo(Bar bar) {
return bar.a.length() + bar.b.length();
}
라는 코드가 있다 했을 때 해당 라인에서 NPE 가 발생했을 경우 a 가 null 인지 b 가 null 인지
모호한 부분이 있습니다. 물론 라인을 나눠 쓰면 되기도 하겠지만 매번 고려하기도 힘들고,
null 일 경우에 대한 특화된 처리를 a 와 b 에 접근하는 다른 부분에서도 항상 해 준다면 비효율
적이기도 하구요. 이것은 매우 간단한 예이고, 여러 레이어로 이루어진 서버 어플리케이션의
경우 그 효과가 2 레이어 뒤 (심지어는 다른 머신)에 나타난다던지 하여 골치가 아플 때가
있습니다.
하지만 만약 setter 에서 set 하는 녀석이 null 일때 NPE 를 던지거나, 이를 빈 문자열로
자동 치환한다면 일이 훨씬 수월해 집니다. 생성자이든 setter이든 어디에선가는 가능한 한
조기에 문제가 생겼을 경우 이를 해결하거나 알려야 코드의 리스크가 감소될것이라는게 제
생각입니다.
setter 와 getter 가 번거롭고 비효율적인 면이 있는 것은 맞지만 아예 불필요한 것은 아니라는
것이죠. 영록님과 그렇게 큰 견해 차이가 있는 것은 아닙니다. 개체가 immutable 이라면
당연히 Constructor 를 이용한 초기화를 선호하고, 파라메터가 많을 경우 좀더 다양한 타입을
만들어 파라메터 수를 줄입니다. 다만 저는 setter 를 써야 할 경우 de facto standard를
약간 보수적으로 따르는 면이 있다고 봐야 겠죠?
--
what we call human nature in actually is human habit.
--
http://gleamynode.net/
|
제목 : Re: 그 부분은 해결책이 있습니다.
글쓴이: 박영록(poci) 2004/11/16 14:18:59 조회수:998 줄수:41 |
|
getter 메쏘드를 이용할 경우 필드별로 부가적인 작업이 요구될 경우 처리하기가
쉽다는 장점이 있는 것은 사실입니다. 그러나, 그 부가적인 작업들이 대체로
validation, null 처리, 타입 변환 등임을 감안해본다면 오히려 Map을 쓰는 것이
더 편리할 수가 있습니다. Map을 상속해서 get을 오버라이드해서 get(key, defaultValue)와
같은 방식으로 사용하게 할 수도 있고, XML 설정이나 클래스 내부의 약간의 코드를
통해서 validation을 편하게 할 수도 있습니다. 일반적인 DTO라면 이런 문제에서도
Map이 빈즈보다 낫다고 할 수 있습니다. 예의 그 코드는 이렇게 바꿀 수 있겠죠.
int foo(MapWrapper bar) {
return bar.get("a", "").length() + bar.get("b", "").length();
}
get(key)는 get(key, "")를 자동으로 실행한다든지 할 수도 있겠죠.
set을 오버라이드해서 기본적인 validation을 수행하게 할 수도 있을 꺼구요.
업무 영역이 늘어날수록 매번 빈즈 클래스를 만드는 것보다 이런 방식이 더
생산적일 겁니다.
그리고 사실 빈즈가 관례이긴 하나, DTO에 있어서는 Map 역시 마찬가지입니다.
현재 추세로는 분명히 DTO로 Map을 사용하는 라이브러리들이 늘어가고 빈즈를
사용하는 것은 줄고 있습니다.
그러나, 웹보다 일반 서버 개발을 많이 하신다면 아마도 단순한 DTO보다는
기능이 풍부한 도메인 오브젝트가 더 필요한 상황일 것입니다. 이런 경우는 많은
프로퍼티들의 처리를 위해 getter & setter가 유용하게 쓰일 수 있을 것입니다.
그러나, 이런 도메인 오브젝트 역시 Map을 상속하거나, wrapping해서 만들 경우
단순 프로퍼티들의 처리를 상당히 편리하게 할 수 있습니다. 객체의 프로퍼티는
모두 내부 Map에 담고 이를 get, set 하는 것은 단순 프로퍼티는 Map의 인터페이스를
그대로 사용하고 중간 처리가 필요한 경우는 부가적인 getter, setter를 만드는
식의 조합이 가능하죠. 저 역시 getter & setter가 적게 쓸수록 좋다고는 생각하지만
완전히 없어져야할 것이라고까지는 생각지 않습니다. 자바의 특성상 완전히
없앨 수는 없기도 하구요.
코드 생성이 언어 차원에서 지원되어서 코드 생성인지 전혀 모르고 사용할 수
있다면 그것은 저도 좋다고 봅니다. 다만 현재 AspectJ와 같은 방식은 약간은
냄새가 남아 있는 것이 아닌가 싶네요. 그래서 이런 면에서 고민할 필요가 없는
파이썬에 점점 끌리는 건가 봅니다.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀
|
제목 : Re: JavaBeans의 기본 목적은?
글쓴이: 사랑전쟁(lovewar) 2004/11/16 20:19:32 조회수:1028 줄수:26 |
|
JavaBeans의 스펙을 보면 "Software component model을 정의하는 것이다."
라고 되어 있습니다.
그래서, JSP와 JavaBeans간의 연관고리를 다음과 같이 해석할 수 있습니다.
"JSP는 변경되지 않는다. 다만 JavaBeans가 다른 JavaBeans로 변경될 수 있다."
즉, View 단과 Model 단을 각각 원하는 것으로 변경할 수 있다는 사상입니다.
그래서 되도록 JavaBeans의 형태를 따른다면, 차후에 JavaBeans만을 다른 회사의
JavaBeans으로 교체할 수 있다는 것 입니다.(현재의 SI환경에서는 거의 전무하지 않을까
생각합니다.)
모회사의 제품중에 Component를 끼워놓을 수 있게끔, 광고에 나오는 것을 봐서는
아마도 Component쪽으로 가는 방향에서는 JSP와 JavaBeans의 기본 사상을 지키는 것이 좋을 것으로
봅니다.
단순하게 Object의 개념으로 코딩을 한다면, 구지 JavaBeans의 규약을 지킬 필요는 없습니다.
-- 덧붙이는 글 --
여기서 빈즈란 개념은 JavaBeans 또는 Enterprise JavaBeans의 개념으로 보시면 됩니다.
빈즈의 규약은 다음 사이트에서 찾을 수 있습니다.
http://java.sun.com/products/javabeans/downloads/index.html
|
제목 : Re: 필요한곳에 쓰십시요.....
글쓴이: 이규주(29zu) 2004/11/16 23:56:25 조회수:994 줄수:13 |
|
웹플밍에서 데이터성 클래스등의 필드에 대한접근을 getter setter로해봤자..
개발시간만 늦어진다고 생각합니다...
일단 이런 클래스는 재활용같은건 기대도 할수없으며 getter setter통해서 접근할
이유도 별로 없습니다...단순히 화면에 한번뿌리는 역할등인데..굳이 공들여
메소드를 만들 이유는 없는거지요..
저같은경우 이런 일회성(?) 에 가까운 기능을 하는 클래스들의 필드는 상당수
public로 처리하고있구요...
공통컴퍼넌트와같이 외부의 다른사람도 쓸지모르는 클래스의 경우엔..
필드접근을 setter/getter를 통해서 하게합니다....
|
제목 : Re: 필요한 곳에서만 getter/setter를 사용하는 것이 좋겠죠
글쓴이: 윤남영(skywatch) 2004/11/17 01:35:49 조회수:1043 줄수:53 |
|
저 역시 getter/setter는 필요한 곳에서만 사용을 하는 것이 좋다고 생각을 합니다.
요즘은 보통 빈즈라고 얘기하면 범위가 넓게 얘기를 하기 때문에 (보통 일반 클래스들도
빈즈라고 칭하는 경우가 많더군요...저도 종종 그런 경우에 당황이 되더군요...)
조금 범위를 구분을 지어 보면 DTO나 Value Object 등의 경우에는 저는 getter/setter를 거의
사용하지 않습니다. 그리고 이와는 조금 다른 의미인 비즈니스 로직을 담는 자바빈즈나
EJB의 경우에는 getter/setter를 반드시 사용을 합니다.
VO의 경우에는 보통 특정 데이터 구조를 나타내는 것이기 때문에 굳이 객체지향의
Encapsulation이나 Information Hiding의 특성을 나타낼 필요는 없다는 생각입니다.
물론 특정 값에 대한 검사의 문제 및 어떤 값이 설정이 될 경우에 자동으로 어떤 로직을
담아야 하는 경우도 생길 수 있는데 이럴 경우에는 조금은 넓은 의미의 getter/setter를
사용하기는 합니다. 머 예를 들면 여러개의 attribute의 값을 조합해서 특정한 값을
자동으로 만들어 내야 하는 경우 등에 getter를 사용을 합니다.(^^;; 엄밀히 말해서 이러한
기능을 하는 메소드를 단순히 getter라고 할 수 있을지는 조금 애매한 것 같습니다. 보통
getter라고 얘기를 하면 특정 attribute의 값을 리턴하는 경우를 말하는 것으로 대부분
생각하고 있기 때문에 그래서 일단은 넓은 의미에서의 getter라고 얘기를 했습니다.)
개발에서 이런 식으로 public 필드를 가진 VO를 사용할 경우에는 얘기가 나올 수 있는 부분이
로직의 변경에 대한 부분일 것 같습니다. 그렇지만 실제로 VO가 변경이 되어야 하는 경우에는
해당 VO를 사용하는 JSP 및 비즈니스 로직을 담고 있는 클래스 역시 같이 변경되어야 하는 것이
보통이겠죠. 예를 들어 특정 데이터 항목이 추가가 된 경우에는 당연히 DAO 및 Entity Beans
역시 변경이 되어야 할 것입니다. 그래서 이러한 데이터나 로직의 변경은 필연적으로 관련
부분의 변경을 보통은 가져오기 때문에 getter/setter를 사용하는 경우와 큰 차이가 없어
보입니다.
그리고 VO의 필드 값에 대한 에러 처리 및 데이터 처리 룰은 VO 보다는 비즈니스 로직을 담고
있는 클래스나 Session Beans 등에서 처리를 해주어야 하는 부분이기 때문에 그러한 부분에
대해서도 역시 public 필드를 가진 VO를 사용하는 것에 대한 부담은 없는 것 같습니다.
흠... 한가지 더 얘기를 하면 컴포넌트화나 모듈화를 할때 이와 같이 public 필드를 접근할 수
있도록 한다면 문제가 생길 수는 있을 것입니다. 대표적으로 동일 컴포넌트의 이전 버전과의
호환성과 같은 문제가 생길 수 있겠죠. 그렇지만 컴포넌트나 특정 비즈니스 로직을 가진
클래스의 내부적인 부분의 변경은 보통 외부적인 변경을 가져오는 것 같습니다. 특히 VO가
변경이 되어야 하는 경우가 있다면 해당 도메인 모델에 변경이 있는 경우가 될 것입니다.
즉 데이터를 가져오는 부분이나 저장하는 부분 등이 변경이 되어야 하는 경우겠죠. 이러한
경우에는 어짜피 기존 컴포넌트와는 달라지기 때문에 조금 다른 데이터/비즈니스 로직을
가지는 새로운 컴포넌트로 보는 것이 좋을 것 같습니다. 그래서 이러한 경우는 기존의
클래스를 확장(extend)하거나 새로 컴포넌트를 만들어서 기존의 컴포넌트를 참조??
(association즉... 가져가 사용하는 것을 말합니다..^^;; 마땅한 어휘가 생각이 안나네요.)하는
형식으로 구현을 할 수 밖에 없겠죠.
머... 개인적으로 public field를 주로 사용하고 있기 때문에... 간단히 변명?? 을 해 봤습니다.
제가 쓴 VO에 대한 내용에 조금 한정을 지어 보면... 제가 얘기한 VO는 주로 웹개발 쪽에서의
방법에 어울릴지도 모르겠습니다. 서버쪽이나 프레임워크 쪽의 개발에서는 실제로 단순한 VO는
거의 사용이 되지 않으니까요. ^^;; 그러고 보면 조금의 얘기의 주제에서 벗어난 얘기가 된 것
같습니다. 맨처음의 질문이 Beans에 대한 것이다 보니까...아무래도 사랑전쟁님이 말씀하신
JavaBean 또는 Enterprise Java Bean의 개념으로 보면 비즈니스 로직을 주로 담고 있어야 하기
때문에 getter/setter는 필수적인 요소 겠지요..
ㅎㅎㅎ 글을 써놓고 보니까... 왠지 예날 얘기의 "이것도 옳다, 저것도 옳다" 라는 글을 쓴 것
같습니다.
|
제목 : Re: 또 배가 산으로 가는군요
글쓴이: 손님(guest) 2004/11/23 16:42:11 조회수:1347 줄수:33 |
|
또 배가 산으로 가는군요.
JavaBean는 선에서 내놓은 Component Spec. 이름입니다.
ActiveX는 MS에서 내놓은 Compnent Spec.을 구현한 제품 이름입니다.
습관적으로 get/set name convension을 쓰는것이 아니라 Spec. 이기때문에 쓰는겁니다.
setter가 좋지않다고 말을 하는 이유는 Thread Safe 문제 때문이고 적절한 sync를 고려
하면 나쁜것은 아닙니다.
get/set method를 이용해서 property에 접근을 한다는것 자체가 JavaBean이란 뜻입니다.
여기에 많은 수식어가 붙죠?
캡슐화, BlackBox, Interface..
Object가 메소드/프로퍼티/이벤트 의 특성을 만족하면 자바빈즈라고 불릴 수 있습니다.
놀랍습니다. 자바빈즈를 표준이 아니라고 하는 사람이 있다니요!! 게다가
자바빈즈를 표준이 아니라 '악습'이라고 말한 사람이 있는데...
사람이 무식하면 용감하다는 말이 다시한번 떠오릅니다.
왜 책에 "javabean을 이용한.."이란 말이 나오는지 한번 생각해 보십시요.
폼생폼사때문에 쓰는 말이 아닙니다.
질문하신분..
옆자리에 있는 사람에게 될 수 있는대로 get/set을 써라고 말씀해 주시고property는
꼭 private 혹은 protected로 붙이는 습관을 들이라고 말씀해 주세요..
몇글자 더 치는게 그렇게 힘듭니까?
|
제목 : Re: 저는 배가 맞게 간거 같은데..
글쓴이: 서민구(guest) 2004/11/23 20:26:48 조회수:1029 줄수:29 |
|
그래서 이런말이 있죠..
"악화가 양화를 구축한다"고요..
단지 스펙이라는 논리만으로 자바빈즈의 setter/getter를
사용해야한다면, 오늘 우리는 스펙이라는 이유만으로 ejb의
모든 퍼시스턴스 레이어는 항상 cmp로 작성해야하게요...?
그리고 tcp/ip는 갈아엎고 깨끗한 osi 7 layer에 맞게
새로 만들어야겠네요..
전 윗 글들을 따라가서 읽다보니, 분명 자바에서는 메타 정보를
표현하는데 있어서 부족함이 있는건 사실이라는 생각이 드는데요..
닷넷하고 비교해보아도 쉽게 알 수 있는데..
닷넷에서는 property라는 개념을 사용해서,
그 필드가 public 필드인지 아니면 프로퍼티인지
클라이언트 입장에서는 모르는 상태에서 접근이 가능하죠...
캡슐화, 블랙박스, 인터페이스와 같은 단어에는 또 이런 응수가
가능하죠.. 'software architecture는 another indirection만
있으면 만사가 해결될거라고 착각하는 사람들의 작품이다'라고요..
setter가 좋지 않은 건 thread safety때문이라니, 그 이유가
정말 궁금하군요...
몇글자 더 치는 귀찮음증이라.. 아마 그런 귀찮음증이 없었다면
사회의 발전이 없었을걸요? 걷기 싫어서 차를 만들고, 차타는것도
너무 오래걸리는게 싫어서 기차를 만들고, 비행기를 만들고.
직접 가서 이야기하는게 힘드니까 전화를 만들고.
인류역사가 이렇게 발전한걸 왜 모른척 하시려는지.
|
제목 : Re: 입장을 바꾸면...
글쓴이: 박찬우(nucha) 2004/11/24 01:00:49 조회수:878 줄수:27 |
|
여러분이 컴포넌트 표준을 만든다고 생각해보세요.
단순히 사용하는 입장이 아닌 만드는 입장에서...
결국 SUN의 입장도 이해가 갈 것입니다.
어느 누군가의 불만을 해결하면 다시 다른 누군가의 불만이 또 나올 것이므로...
그런데 데이타 전송 객체는 자바 빈 수준의 표준을 지키면서 만들수도 있고
public 필드들로만 구성되게 해서 작성할 수도 있습니다.
필요하다면 데이터와 서버로 전달되면 그 데이터로 뭘 할지
로직까지 구현해서 전달할 수도 있습니다.
다 구현하기 나름이지요.
물론 Map을 이용한 데이타 전송 객체도 그 한가지 방법입니다.
그 것은 선택의 문제일 뿐입니다.
맘에 안들면 안쓰면 되는 것이지요.
왜냐하면 제각각 장단점을 가지고 있어서
자신에게 맞고 편리한 것을 선택하면 그 것이 자신에겐 최선의 선택인 것입니다.
그렇다고 자신이 선택하지 않은 다른 것을 나쁘다고만 할 수는 없는 것이지요.
ps:
그런데 Map을 상속받아 구현하는 것보다 위임으로 작성하는게 좋을텐데요.
사용하는 구체적 Map이 무엇이든 간에...
|
제목 : Re: JavaBeans의 뒤틀림
글쓴이: 이원영(javaservice) 2004/11/24 03:53:04 조회수:1727 줄수:35 |
|
조금 위로 거슬로 올라가서, 처음 "JavaBeans"가 대두되었을 때, 원래의 그 취지를
되짚어 봤으면 합니다. 98년도에 제가 작성한 아래의 첨부파일이, 지금의 논란에 바람직한
방향으로의 이해에 도움이 되었으면 합니다.
첨부: JavaBean_전략보고서.doc (잠깐 둘러보시죠..)
사랑전쟁님이 미리 언급하신 JavaBeans의 규약에도 보면,
http://java.sun.com/products/javabeans/downloads/index.html
...that allow for the visual construction of applications
이라 되어 있어요. 이것이 서버측의 EJB모델로 이어지고, JSP에서 JavaBeans가 활용되고,
지금 이 쓰레드에서 일파만파 이어지고 있는 Server-side programming model의 얘기로
전해 내려오고 있습니다.
제 생각은 JavaBeans는 "Visual construction"를 위한 기가막힌 이상적 모델이었습니다.
단지 CBD(Component-Based Development)가 생각만큼 현실화되지 못했고, Visual Cafe,
JBuilder, ViualAge for Java/WSAD/Eclipse 등의 IDE Tool들이 Visual Construction-Based
Component를 양산할 것으로 기대되었으나, 현실적으로 그러하질 못했고, 결국 이름만
JavaBeans로 덩그러니 남아 있는 형국으로 보입니다. 안타깝죠.
server-side에서의 JavaBeans활용은 그 효용성과 가치를 부단히 찾아가려 노력했지만,
저를 포함해 많은 분들이 이미 그다지 높은 점수를 주고 있는 것 같지는 않네요.
3박자가 모두 맞아떨어졌어야 했습니다.
1) Visual Construction기반 개발 대중화
2) 다양한 Visual Component의 생산 및 판매(그러한 전문업체의 성장)
3) CBD 애초 의도대로의 실질적인 발전
이 3가지가 90년대 말에 추정했듯이 예상대로 진행만 되어 졌더라면, 그 중심에는
JavaBeans가 있었을 거예요. 그러나 현실은 그렇지 못하고, setter와 getter를 개발자가
코딩하고, 그것의 이용도 개발자의 editor에서 코딩되니, 그 가치와 의미를 이미 상실한
것이라 봐요.
자바서비스넷 이원영
 JavaBean_전략보고서.doc (830976 Bytes)
|
제목 : Re: JavaBeans
글쓴이: 서민구(guest) 2004/11/24 09:08:16 조회수:874 줄수:25 |
|
죄송합니다. 앞서 글에서 제가 사실 '손님'님의 글에 흥분한 나머지 삐딱하게 답을
달았습니다.
제 생각을 좀 더 명확히 하자면,
(1) VO에서 Map 등의 사용이 편한 것은 사실이고, 단순 public field 가 편한 것도 사실.
더구나 만능 VO를 만들 목적이 있다면 Map이 유리한 것도 사실.
예를 들자면, select 해온 모든 필드를 키로 갖도록 동적으로 Map을 만들어
반환한다든가..
(2) 하지만 역시 표준이 아닌 건 사실.. 이로 인해 모두가 합의하는 필드 값에
대한 validation 방식이 Map에 대해 없죠. 물론 프로젝트나 팀이나 회사 단위로
이에 대한 표준화가 이루어진다면 얼마든지 Map을 써도 상관없겠지만,
모두가 합의하는 방식이 되기는 힘들단 거죠..
getter/setter보다 더 나은 대안이 나오기 힘들기는 하지만, Map을 사용하되
여러가지 사항을 잘 고려하면 (가령 키를 조작하지 못하게 반환하거나 값을
할당할 때 값의 validatin을 해줄 수 있게 하거나) 코드가 더 나아질 수 있다는
생각이 드네요...
하지만 표준이 아니라는 이유만으로 다른 방향으로의 생각이나 발전을 거부한다면,
스트러츠 같은 프레임웍이나 자바 세계의 다양한 퍼시스턴스 레이어(얼마나 많은지
이젠 일일히 공부할 수가 없죠)나, GNU GPL 내의 다양한 프로젝트들은 있을 수
없었을지도 모르죠.
|
제목 : Re: 머 그런걸로..
글쓴이: 손님(guest) 2004/11/24 17:03:13 조회수:809 줄수:20 |
|
머 답글보고 삐딱하게 반응까지야..
JavaBeans 자체를 데이터 Container 역활로 한정시키니까 Map이니 getter/setter 니 뭐니
그런 말들이 난무하는겁니다.
그런 용도로 쓸려면 Thread-safe한 Collection들 많이 있으니까 걍 그것 쓰면 되구요..
JavaBeans가 현재 가치와 의미를 상실했다는 말은 3rd party 개발자로서 동의할 수
없습니다.
(사실 코어클래스들은 모두 빈즈라고 할 수 있기때문에 JavaBean란 말이 쉽게 쓰입니다)
말만 앞세우는 개발자는 믿지 않은지 오래됐기땜에..
앞으로 증명해 보이겠습니다..
P.S.
JavaBeans 정의 자체에 'Visual' 이란 말이 들어가는 바람에 개념에 상당히 혼란을 주는
점은 역시 초창기 server-side를 의식하지 않은 때문으로 보입니다.
뒤에 Non-Visual이란 말이 나오지만 이건 상당한 불만입니다.
|
제목 : Re: JavaBeans의 불투명한 방향성
글쓴이: 이원영(javaservice) 2004/11/24 19:13:58 조회수:1502 줄수:36 |
|
"코어클래스들은 모두 빈즈"라는 행간의 의미는 임의의 클래스는 Beans의 instantiate()라는
메소드를 통해 "JavaBeans화" 될 수 있다는 뜻입니다.
예를 들면, JSP에서 <jsp:useBeans ...> 라고 했을 때, precompiled된 java 소스를 보면,
Beans.instantiate(...) 를 통해 해당 클래스가 JavaBeans의 특성을 모두 갖는 Beans로
instance화 되는 것이지요.
http://www.javaservice.net/~java/docs/j2sdk_1.3.1/api/java/beans/Beans.html
JavaBeans에 관한 김세종님의 (오래된)강좌도 읽어봄직하지 않나요?
http://www.javaservice.net/~java/bbs/search.cgi?m=resource&b=applet&p=0&c=search&k=...
아시다시피 자바빈즈는 Delegation Event Model, Property, Introspection, Persistency,
core Reflection, Customization 등의 특성을 갖고 있습니다.
그러나, 우린 지금 다소 "Property"라는 속성만 놓고 JavaBeans에 대한 얘기를 끌어오고
있는 듯 해요. 그러나, 위에 나열된 JavaBeans의 상당부분은 "Visual construction"를
위한 것이었다는 것을 강조하고 싶고, "Visual"을 뺀 non-visul JavaBeans는 그러한 관점에서
(다소) 의미를 상실했다는 것이지요.
Server-side에서의 JavaBeans활용은 분명 가치가 있을 겁니다. 그러나, 그 장점이 극대화
되기 위해선 IDE Tool에서 Visual Construction 개발방법이 가능해져야 했던 것 아니냐라는
것이지요.
저역시 editor를 이용한 코딩시에 Entity-Object에서 setter/getter를 굳이 만들 필요가
없다고 보여지며, (역설적으로) reflection 기능을 이용하여 public field의 setting/getting이
(경우에 따라!) 보다 생산적이더군요. 심지어 JSP에서 <jsp:useBeans ...> tag를
써야할 이유를 찾지 못합니다. 그러한 코드가 IDE Tool에 의해 Component-Based Drag&Drop으로
자동생성되는 것일 때, 의미를 갖는 것 아닐까요.
PS: 98년도엔, "JavaBeans와 EJB(Enterprise JavaBeans)는 이름만 Beans이지 전혀 다른
것입니다"라고 했는데, 이젠 다들 광의의 관점에서 "유사한 것입니다"라고 여겨지나봐요.
NOTE: "JavaBeans의 방향성"이나, server-side programming시에 JavaBeans 속성 중 어떤
속성은 어느 부분에서 매우 활용가치가 높다, 혹은 server-side component의 visual
conctruction 개발 방향이 어디로 흐르고 있다, 등에 대해 말씀해 주시면 감사하겠습니다.
자바서비스넷 이원영
|
제목 : Re: JavaBeans와 표준..
글쓴이: 박영록(poci) 2004/11/24 20:56:29 조회수:1425 줄수:43 |
|
JavaBeans를 표준이라고 말하기에는 다소 어폐가 있습니다. JavaBeans 스펙은
beans를 다루는 API에 대한 것이지 어떻게 클래스를 코딩할 것인가에 대한 표준은
아닙니다. 프로퍼티들을 public field로 쓰거나 Map으로 관리한다고해서 이것이
비표준인 것은 아닙니다. 그보다는 일반적으로 객체의 프로퍼티를 자바빈즈 스타일로
관리한다는 점에서 이희승님의 말씀처럼 de facto standard라고 보는 게 맞겠죠.
그리고, 이런 시각에서 본다면 최소한 DTO의 영역에서는 Map 역시 de facto standard가
되어가고 있습니다. iBatis, Spring DAO, commons-dbutils 등의 JDBC 래퍼들이
이런 경향을 반영하고 있고 JSTL의 EL 역시 마찬가지입니다.
자바빈즈가 처음에는 visual component를 목표로 출발한 것은 사실입니다만
자바빈즈의 특징들이란 게 사실 빈즈로 코딩된 클래스 자체가 가지는 특징은
getter/setter 밖에 없습니다. 그 외에는 빈즈의 특징이 아니라 빈즈를 지원하는
API들의 특징이죠. 요즈음 일반적으로 사용하는 빈즈의 의미는 이런 프로퍼티
관리 이상의 의미를 크게 담고 있지 않습니다. XMLBeans, commons-beanutils,
스트러츠의 FormBean 등에서 사용하는 beans의 의미는 프로퍼티 관리를 getter/
setter로 한다는 정도의 의미로 사용되고 있죠. 그렇다고 이것이 beans는 모두
단순 getter/setter만 가진 DTO를 의미하느냐하면 그건 아닙니다. full-featured
object이더라도 자신의 프로퍼티를 getter/setter로 관리한다는 것 뿐이죠.
사실 이런 게 논란이 되는 이유는 자바이기 때문일 수 있습니다. getter/setter
방식이 단점이 많음에도 불구하고 쓰일 수 밖에 없는 것은 Map이나 public field가
가지기 힘든 장점, 프로퍼티 접근 과정에서 부가적인 프로세스를 수행할 수 있다는
점 때문이죠. 이런 점은 사실 프로퍼티라는 개념을 별도로 지원하는 언어들에서는
고민할 필요가 없는데 자바이기 때문에 고민할 수 밖에 없는 것 같습니다.
p.s. component의 visual construction은 원래 자바빈즈의 목적이긴 하지만
요즘 통용되는 의미의 자바빈즈와는 거리가 있고 자바빈즈에만 연관시켜서
이야기하기엔 조금 큰 주제인 듯 합니다. 많은 사람들이 관심 갖고 있는
주제이기도 하니 새로 쓰레드를 열어보는 것은 어떨까요?
----
http://youngrok.com
NHN Corp. 웹플랫폼팀
-------------------------------------------------------
게시판관리자주: Visual construction 이슈는 아래의 스레드로 분리하여 이어집니다.
332 Visual component 와 Visual construction 은 다른거 아닐까요
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=discussion&c=r_p&n=1101340367
|
제목 : Re: 오호....
글쓴이: 손님(guest) 2004/11/26 23:12:17 조회수:1161 줄수:61 |
|
JavaBeans는 de facto standard가 아니라 standard입니다.
getter/setter는 전혀 중요한 문제가 아닌데 이렇게 강조하는 이유를 모르겠습니다.
(Object 멋대로 만들어서 걍 쓰세요.. 아무 문제없습니다.)
API란 말의 의미는 '이런 Spec.을 만족하는 뭔가를 만들려면 이렇게 해라' 라고 하는 표준
입니다. API의 I는 Interface란걸 명심하십시요.
이말은 곧 'Java 프로그램을 만들려면 이걸 이용해서 이렇게 해라..' 란 뜻올시다..
(이런것까지 설명을 해줘야 합니까?)
System.out.println("hello?");
hello? 란 말을 console에 뿌릴려면 out 즉, java.io.PrintStream이란 Interface를 이용하란
말입니다. 댁이 그래픽 디바이스 API를 얻어서 뿌리실려우?
그 많은 그래픽 카드 벤더들 API들 다 연구해서?
도대체 standard를 무의식중에 이용하면서 de facto라니요..
이야기가 잠시 샜는데.. 위에도 이야기했지만 getter/setter는 전혀 중요한게 아닙니다.
아... 개인적으로 reflection보다는 interface를 좋아합니다. 취향문제겠지요..
제가 이야기하고 싶은것은..
사람들이 왜 EJB하면 Business Logic을 떠올리면서 JavaBeans를 이야기하면 단순한 데이터
저장소를 떠올리냐는 것입니다.
(EJB와 JavaBeans는 완전히 틀립니다. Spec.이 틀리지않습니까?)
(사실 EJB로 99년도에 사업화를 생각했었지요.. 50Kbyte 하나 deploy시키는데 1000만원
듭디다.. 젠장..)
JavaBeans 역시 거대한 Business Logic 을 가진 객체덩어리입니다.
JVM 위에서 돌아가는 Business객체 덩어리..
이 자체가 흥미롭지 않습니까?
JavaBeans 컴포넌트를 IDE Tool에서 drag & drop 해봤자 소스보면
SomeJavaBean bean = new SomeJavaBean();
입니다. IDE는 Introspection을 통해 이 jar파일이 javabeans란 것을 인식하고 property
와 event를 설정할 준비를 하는것뿐입니다.
IDE가 원하는건 Interface뿐입니다.
Interfaec는 곧 Spec. 전문용어로 표준입니다.
할 이야기는 많지만 이 Interface를 부정하는 글뿐이니.. 힘이 쫙 빠집니다.
이원영님 말씀대로 JavaBeans가 제대로 방향을 잡을려면 CBD가 정착이 되어야합니다.
그러나 그전에 CBD가 뭔지를 서로 이해가 되어야 할것같습니다.
그렇지 않으면 이야기가 계속 겉돕니다.
CBD, Interface, 강한 내부응집력, 완전한 BlackBox..
이것도 극히 개인적인 취향입니까?
P.S.
public 접근자를 가지는 property를 좋아하는 사람이 있다니..
이건 정말 의외입니다.
좋아하는 여자 사타구니를 개나소나 아무 제한없이 만질수 있단 이야기인데..
현실에서도 가능하지 않은 이야기를 컴퓨터상에 구현을 한다?
너무 KTF적인 생각아닙니까?
|
제목 : Re: 고정관념
글쓴이: 박영록(guest) 2004/11/27 02:06:20 조회수:1019 줄수:36 |
|
String vs StringBuffer에서도 느꼈는데 무언가 한 번 주입된 고정관념을 깨지 않으려는
종류의 사람들이 세상에는 참 많은 것 같습니다. 고정관념을 깨고 세상을 한 번 보십시오.
세상은 당신이 변하는 것보다 훨씬 빨리 변하고 있습니다. 아마도 이런 종류의 사람들이
고정관념을 쉽게 깨지 못하는 이유는 다른 사람의 의견을 주의깊게 살피지 않기 때문이
아닌가 합니다. 나름대로 다른 생각을 접하고 다시 한 번 고민해보면 좋은 기회가 될
수도 있는 것을 고정관념 때문에 날려버리고 있지는 않나 생각해보셨으면 좋겠군요.
1. public 프로퍼티와 private 프로퍼티 + public getter/setter는 접근성이 완전히 동등합니다.
결코 더 KTF적인 생각은 아니죠. 자바빈즈는 블랙박스가 아니라 화이트박스입니다.
주입된 지식을 잠시 접어두고 '상식적'으로 생각해보십시오.
2. "JavaBeans 역시 거대한 Business Logic 을 가진 객체덩어리입니다."라고 하셨는데..
자바의 모든 객체는 비즈니스 로직을 가진 객체 덩어리일 수 있습니다. 이런 자바 객체와
구분되는 자바빈즈의 특징이 무엇일까요?
3. 자바빈즈를 이야기하면서 인터페이스를 이야기하는 의도도 조금 혼동됩니다.
reflection보다 interface를 좋아하신다면 당연히 자바빈즈를 싫어하셔야할 것 같은데요.
그 introspection이 어떻게 동작하는 거라고 생각하시는 건지?
4. 물론 빈즈 API에 맞게 쓰려면 자바빈즈의 형식을 갖춰야겠죠. 그렇다고 빈즈 API를
쓰지 않는 객체를 코딩할 때조차 자바빈즈처럼 getter/setter를 갖춰야할까요? 빈즈 API는
표준일지언정 자바빈즈는 결코 프로퍼티 관리 방식의 표준이 아닙니다.
5. 흔히 말하는 좁은 의미의 CBD가 주류로 정착되는 일은 없을 꺼라고 감히 말해봅니다.
CBD는 변화에 약한 방법론입니다. CBD의 성공 사례들은 보통 견고하고 잘 작성된 컴포넌트들을
조립만 해도 requirement를 만족시킬 수 있을 때 뿐이죠. 하루하루 변화하는 requirement를
만족시키기에는 낡은 방법론입니다. 물론 넓은 의미의 CBD라면 RUP 등도 포함될 수 있으니
그리 나쁜 것은 아니지만요.
6. 파이썬은 접근 제한자가 아예 없는 언어임에도 자바보다 더 객체지향적인 언어로 불리고
있습니다. 왜 그럴까요? 파이썬 개발자가 KTF적인 사람이라서?
----
http://youngrok.com
NHN Corp. 웹플랫폼팀
code for human, not for programmer.
|
제목 : Re: CBD
글쓴이: 서민구(guest) 2004/11/27 05:17:04 조회수:1258 줄수:52 |
|
앞에 '손님'님 한번 이렇게 생각해보세요.
CBD라고 말할때, 컴포넌트라는 단위가 무엇인지요..
우리가 EJB를 디플로이할때의 단위인지,
아니면 EJB내의 클래스 하나하나가 컴포넌트인지.
컴포넌트로 제대로 동작하려면 그것을 어떤 곳에 옮겨놓아도
인터페이스를 통해서 정의된 동작을 수행하면 되죠..
그런데 그 컴포넌트가 JAVA 클래스 한개인지에 대해서는
생각해 볼 필요가 있는 것 같네요..
예를들어, 하나의 웹 서비스를 만들어서 이를 등록시켰을 때
이 서비스는 잘 정의된 통신 규약인 SOAP으로 동작하고,
서비스 종점 및 제공하는 서비스는 UDDI에 등록되어있을 때
그 서비스 내의 하나하나의 자바 클래스가 다 완전한
추상화가 되야할까요? 그것도 현재로서는 불필요하다고 생각되고,
미래에는 일어날지 안일어날지도 모르는 검증을 위해 모든 field 를
private으로 만들면서요?
저는 그런 완전한 추상화에 대해서 상당히 회의적인 입장이거든요.
아마 마틴 파울러역시 내부에서 쓰는 클래스를 인터페이스를 사용한
publish를 하지 말라고하죠..
http://www.artima.com/intv/principles3.html
인터페이스나 블랙 박스나 하는 개념이 나쁘다는게 아니라, 그것을
어떤 업무 단위에서 블랙 박스로 만들고 인터페이스로 만드는 게
낫다는 이야기이죠..
사실 자바의 자바 빈즈라고 하면 어디나 갖다놓아도 잘 동작하는
바이너리 비즈니스 로직이라고 말할 수 없는게, 그건 어디까지나
자바 언어와만 통신하는 거라고 생각합니다.. 그리고 그런 자바
클래스를 묶어서 이기종환경에서도 완전히 통신가능한 서비스 형태로
만들자는게 지금의 이야기인데 (심지어 사람들은 API의 시대는
가고 SOA의 시대가 갔다고까지 말하죠...), 그렇게 제공되는 서비스
내의 자바 클래스들이 모두 자바빈즈 규약을 따라야할런지.
완전한 추상화는 미래에 대한 투자이지만, 만약 미래에 투자한
노력에 대해 돌아오는 것이 전혀 없다면 어떻게 될까요..?
drag & drop 으로 그림 그리듯이 프로그램을 짠다.. 라는 개념도
그리고 자바 빈즈 - 클래스 - 단위 보다는 훨씬 큰 비즈니스 로직단위로
그림 그리듯이 짠다.. 라는게 또 MDA의 흐름 아닌지..
요즘은 유연하게 코드를 바꿀 수 있어야한다.. 라는게 대세가 아닌가
(옳건 그르건 간에)라고 생각이되고, 그런만큼 세세한 단위에서
추상화는 지양하게 되지 않나 생각되네요.. 제 코딩 스타일도 그렇고..
역시 파울러는 같은 일을 두번할때까지는 그냥 두번 한다, 세번 해야한다고
하면 그땐 한번만 하도록 고친다..라고 말했죠.
인터페이스가 필요없다고 말하는 건 아닙니다..
다만, 그 단위가 어떻게 되느냐를 다르게 볼 뿐인 듯.
|
제목 : Re: 잠시 덧붙여..
글쓴이: 황종훈(guest) 2004/12/02 13:23:13 조회수:803 줄수:46 |
|
박영록님의 첫번째 글에서
"파이썬이나 그루비 등의 언어에는 public, private와 같은 접근 제한자가 없습니다.
객체의 필드는 직접 접근할 수도 있고 "
다음과 같은 부분이 있는데요. 파이썬은 모르겠으나 그루비 같은 경우
물론 접근 제한자는 없지만, 필드를 직접 접근하지 않습니다.
class Foo{
String name;
}
과 같은 클래스는 public필드 하나 있는 것 처럼 보이지만 사실 내부적으로
set과 get을 만들고 있습니다.
class Foo{
String name;
Foo(){
name = "my name is foo."
}
String getName(){
println "....getName()"
return "my name is not foo."
}
static void main(args){
foo = new Foo()
println foo.name
}
}
다음과 같은 groovy화일 실행시 "....getName()"과 더불어
"my name is not foo."이 출력됩니다.
public필드접근이라면 "my name is foo."가 출력되야 하겠죠.
한마디로 groovy자체가 코드제네레이터라는 겁니다.
뭐 참고로 빈즈가 악습까진 아니더라도
저도 박영록님과 Map에 대한 생각이 비슷합니다.
----
by 이즌해
|
제목 : Re: Active Code Generation
글쓴이: 박영록(poci) 2004/12/02 13:51:21 조회수:971 줄수:18 |
|
제목 : Re: 프로퍼티접근에 대한 부연설명
글쓴이: 황종훈(guest) 2004/12/02 22:15:25 조회수:905 줄수:32 |
|
예 맞습니다.
전 groovy의 필드 접근이 파이썬, C#등의 프로퍼티 접근과 유사한
뭐 그런거라는 것을 보여드리고 싶었던 겁니다.
박영록님의 "객체의 필드는 직접 접근할 수도 있고" 라는 말에 오해의 소지가 있어
올려드렸던 겁니다.
박영록님께서 바로 위에서 말씀하신대로 저 접근은 프로퍼티접근입니다.
제가 말을 다시 바꾸자면
"객체의 필드를 getter,setter없이 직접 접근하는 것처럼-public처럼-접근 할 수 있고,
필요에 따라 getter,setter을 두어 프로퍼티 접근에 부가적인 기능을 지원할 수 있다."
뭐 이정도 되겠습니다.
박영록님께서는 이 사실을 알고 계신다 하더라도
읽으시는 분이 오해할 소지가 있어 올린 것 뿐입니다.
(특히 '자바'만 접하신 분에게)
'내부적으로 코드 생성해서 문제'가 있다고도,
'접근 제한자의 문제'라고도,
'자동 코드 생성은 별다른 문제가 있다'고도 하지 않았습니다.
지금까지 박영록님께서 말씀하시고자 하는 바도 다 알겠고,
전부 다는 아니지만 저도 생각했던 부분이며 동의하고 있습니다.
문제라고 말씀하시며, 굳이 위키까지 인용 안하셔도 됩니다.
반론이라기보다 오해의소지가 있는 것을 추가설명했다고 생각해 주시면 감사하겠습니다.
------
by 이즌해
|
제목 : Re: 지식은 깊지 않지만...
글쓴이: 민봉기(guest) 2006/04/13 14:23:37 조회수:1400 줄수:18 |
|
굳이 property를 public으로 선언하지 않고 method를 통해 접근함은
데이터를 주고 받음에 있어
변경에 대해 닫혀 있고, 확장에 대해 열려 있기 위함이 아닐까요?
사실 이 말 자체는 아주 단순한 건데...
가령 여러 사람(업체)이 관여한 프로젝트에서 Data Model과 Value Object (bean) 을 누가 정의 하는가?
또 그 빈을 사용하는 사람(업체)이 여럿일 때 각각의 모델, 컨트롤러 단 등에서
기능 확장에 대해 유연할 수 있기 위하여 직접 접근을 스펙으로 하지 않고
메소드를 통해 접근함을 스펙으로 한 것으로 유추해 봅니다.
사실 프로젝트를 개발하는 지금 단계에서 직접 접근 하는 방법이 더 좋은 효율을 낸다고 생각할 수 있을지 모르겠습니다.
하지만, 훗날 누가될지 모르는 수정자가 어떤 변경 사항이 이루어 질지 모르는 상황을 만났을 때
앞서 있던 사람이 유연하게 코딩을 해 놓았다면 혹 곤란한 상황이 줄어들지 않을까 생각해 봅니다.
즉 결론은 지금 당장은 직접 엑세스가 좋은 것이라 판단할진 몰라도, 코드의 변동은 예측할 수 없다는 것과
최대한 뒷 개발자를 위해 유연하게 메소드 접근 방식으로 해 놓는 것을 스팩으로 결정한 듯 하다는 것입니다.
|
제목 : Re: 헉...2년전 글인데 아직도 이어지는군요.
글쓴이: 손님(guest) 2006/04/14 09:29:32 조회수:2024 줄수:3 |
|
위에 실명으로 글 올리신분들, 꽤 알려지신분들 같으신데 effective java
같은 책을 읽어 보셨나 모르겠습니다...2004년도면 자바 초기도 아니고...
조금 실망스럽기도 하고 황당스럽기도 하고...
|
제목 : Re: 헐..
글쓴이: 손님(guest) 2006/04/16 21:06:45 조회수:913 줄수:3 |
|
아직도 effective java 수준에서 놀고 있는 사람이 있다니...
조금 실망스럽기도 하고 황당하기도 하고...
|
제목 : Re: RE: 헐...
글쓴이: 손님(guest) 2006/04/16 23:06:27 조회수:875 줄수:1 |
|
effective java 수준 다음은 어떤 수준일까?
|
제목 : Re: 그건..
글쓴이: 손님(guest) 2006/04/17 06:03:08 조회수:983 줄수:13 |
|
자바를 넘어선 패러다임을 자바에 적용하는 수준을 말하는 것이라오.
자바 밖에 모르면 자바조차 잘할 수 없는 시대가 되어가고 있으니까.
그냥 자기 생각 한 마디도 없이 저 많은 사람들을 다 도맷금으로 넘겨서 비아냥대는
꼬라지가 보기 싫어서 똑같이 비아냉거려 봤소이다.
점점 자바서비스넷에 논쟁다운 논쟁이 사라지고 실명으로 논쟁에 참여하는 사람이
사라지는 게 다 저런 인간 때문 아니겠수.
|
제목 : Re: 윗분 도대체 무슨말인지
글쓴이: 손님(guest) 2006/04/21 00:21:36 조회수:881 줄수:8 |
|
누구에게 하는 말인지 모르겠소.
무슨 꼬라지가 보기 싫어서 똑같이 했다는 것인지.
저런 인간 이란 도대체 누구요?
실명중에 누구요?
|
제목 : Re: 아...
글쓴이: 손님(guest) 2006/04/21 02:55:19 조회수:840 줄수:16 |
|
또 이해 안되는 분 등장이구려. 설명 전문가의 설명 들어갑니다-_-
제목 : Re: 헉...2년전 글인데 아직도 이어지는군요.
이 글을 1번으로 놓고 그 뒤부터 쭉 2, 3, 4번으로 두면
1번은 이 토론에 참여한 모든 사람을 한 번에 비판한 글이고
2번은 1번을 비아냥거린 것이고
3번은 2번 쓴 사람에게 부연 설명을 요청하는 거고
4번은 2번 쓴 사람이 3번 글에 답해 부연 설명을 하는 겁니다.
고로 저런 인간이란 1번 글을 올린 손님이 되겠고
보기 싫었던 꼬라지란 1번 글에서 비판하는 모습이 되겠소이다.
제발 생각 좀 하고 사시구려. 이것도 이해가 안되면 자바서비스넷의 그 많은
꼬리에 꼬리를 무는 논쟁들은 어떻게 이해를 하겠소?
|
제목 : Re: 아뿔싸
글쓴이: 손님(guest) 2006/04/21 09:56:09 조회수:1000 줄수:3 |
|
내가 그만 착각을 하고 실명 글만 해독해 봤구료.
하하하~ 쥐구멍이라도
|
제목 : Re: 좋은 글입니다.
글쓴이: 손님(guest) 2006/06/14 15:54:57 조회수:980 줄수:1 |
|
제목 : Re: ㅎㅎ
글쓴이: 손님(guest) 2006/06/23 17:35:59 조회수:1009 줄수:2 |
|
뭐랄까...좀 씨잘대기 없는 논쟁이 넘 많아요...^^;
너무 똑똑해서들이겠죠...-_-;
|
제목 : Re: 음~~
글쓴이: 나도손님(guest) 2009/12/15 14:09:22 조회수:1797 줄수:4 |
|
getter / setter 와 public 의 차이가 먼지 궁금해서
인터넷 검색중 여기까지 흘러들어왔는데..
이건 멍미 -_-;;;;;; 다들... ㄷㄷㄷ
암튼 잘 보고 갑니다 ㅎㅎ
|
|
