IT 지식 데이터베이스

영어공부를 위한 사이트 소개를 아주아주 잘 해 주신분의 글이다.

네이트 판에 떠서 알게 되었는데..

2011년 7월의 글이다.

http://thinknow.tistory.com/255

영어.. 해야지 해야지 하면서 참 안한다.

자격증.. 따야지 따야지 하면서 참 게으름만 피운다.

이제 하나씩 해야 하겠다.

이러다 언제 시골가나.

공부는 어떻게 하면 재미날 수가 있을까? 궁금하다.

안전행정부 님의

소프트웨어 개발보안(시큐어 코딩) 관련 가이드

위 링크를 클릭 하시오!

• 소프트웨어_개발보안_가이드(2012년_5월).pdf [14.0 byte]

  소프트웨어_보안약점_진단가이드(2012년_5월).pdf [14.0 byte]

  (3판)_JAVA_시큐어_코딩_가이드.pdf [5.0 MB]

  (3판)_C_시큐어_코딩_가이드.pdf [3.0 MB]

  (2판)_Android-JAVA_시큐어_코딩_가이드.pdf [2.0 MB]

  [참고]_SW개발보안_교육일정_및_교육신청_방법.hwp [1,024.0 KB] 

링크가 맞을라나 몰겐네요;;

그럼 keep coding!! ㅋㅋㅋ

구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 구글 두들 오타 작렬!! ㅋㅋ

자유를 갈망하다 든 생각..

두들에 나오는 것들을 하나하나 짚어가며 여행을 다녀 보는건 어떨까?

뭐. 오늘을 예로 메리 애닝을 찾아 떠나본다든가.

루빅스 큐브를 사 본다던가(실제론 이미 다른 버젼이긴 하지만 가지고 있다.)

[두들스 페이지]

두들 검색해 보다가 재미난거 발견 

스타트랙의 킬링곤족을 위한 킬링곤어 검색 근데 되긴 하는건가? ㅎㅎ

[킬링곤 언어로 검색]

압류

채권자 등의 신청을 받은 국가기관이 강제로 다른 사람의 재산처분이나 권리행사 등을 못하게 하는 것.

http://java-x.blogspot.kr/2006/11/merge-pdf-files-with-itext.html

일단 링크하나 투척!!

요구사항

1. 두개의 pdf 파일을 하나의 pdf로 합치길 원함

2. pdf파일의 용지설정이 하나는 가로, 하나는 세로 일때 각각 가로, 세로로 합쳐지길 원함..

삽질 엄청함..

MergePDF.java 파일을 생성

링크에 보면 잘 있다..

import 해야 할 것들은 ctrl + shift + o 를 눌러서 하나하나 선택한다..

하지만 잘 선택하지 않는다면 에러는 면하기 힘들다...

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

import com.itextpdf.text.Document;
import com.itextpdf.text.PageSize;
import com.itextpdf.text.pdf.BaseFont;
import com.itextpdf.text.pdf.PdfContentByte;
import com.itextpdf.text.pdf.PdfCopyFields;
import com.itextpdf.text.pdf.PdfImportedPage;
import com.itextpdf.text.pdf.PdfReader;
import com.itextpdf.text.pdf.PdfWriter;

내가 import 올린 내역을 참조 바란다..

결국 가로로 돌리기는..

도큐먼트 뉴 해주는 부분에서

Document document = new Document(PageSize.A4.rotate());

이렇게 하면 무조건 가로 랜드스케이프로 만 나온다.

혼용은.. 더더더더더더더더더더 간단했다.. 젝일..

import com.itextpdf.text.pdf.PdfReader; 를 임포트 하고..

            PdfReader reader1 = new PdfReader("C:\\PDF1.pdf");
            PdfReader reader2 = new PdfReader("C:\\PDF2.pdf");
            PdfCopyFields copy = new PdfCopyFields(new FileOutputStream("C:\\concatenatedPDF.pdf"));
            copy.addDocument(reader1);
            copy.addDocument(reader2);
            copy.close();

를 하면 되었다.. 두둥...

아.. jar 파일을 다운 받아야 할테니..

아래 파일이고.. 파일명을 보면 알겠지만..

itext를 사용한 pdf 병합 이다..

itext-5.4.1.zip

모르면 삽질하고..

테스트 하고 하고 하고...

하면 되드라..

답은 댓글에서 오히려 더 많이 얻었다..

링크 글의 잘 읽어보삼

해외에서 많은 인기를 끌었고 구글의 레퍼런스 폰이고 LG가 만든 넥서스4가 국내 출시 예정이다. 그런데 나는 늦어도 너무 늦었고 생각한다. 사실 이거 사고 싶은 사람들은 주위에 보면 벌써 외국 사이트를 통해서 사와서 쓰고 있더라. 그리고 지금 갤4가 나오느니 하는 마당에 과연 인기를 끌 수 있을지 모르겠다. 가격이나 왕창 싸게 나오면 모를까? 하지만 기사내용을 보니 가격도 만만치 않은 것 같다. (60만원이다.) 왜 이런 터무니없이 안 되는걸 뻔히 아는 장사를 하는지 모르겠다. 이게 LG와 삼성의 차이인가? ㅎㅎ (LG미안~)

http://www.google.com/nexus/4/

http://www.fnnews.com/view?ra=Sent0901m_View&corp=fnnews&arcid=201303110100092470004830&cDateYear=2013&cDateMonth=03&cDateDay=11

요즘 커피가 대세는 대세인가보다. 한 1년전인가? 이제 관련 조사하면서 개인적으로 커피 수요는 고정적이고 공급은 많아서 사실 성장이 둔화될 것이라고 예측했었는데 틀린 지도 모르겠다. 담배마저 커피의 이미지가 되어가고 있으니 말이다. (근데 에쎄는 중년들이 피는 것 이닌가? 에스프레쏘는 중년들이 좋아하는 커피인가? 하긴… 나이 들수록 뭐든 안섞은게 좋긴 하더만..)

http://news.zum.com/articles/5920385?c=07

이스트소프트에서 알드라이브 v1.0 beta를 출시했다. "편리한 파일 전송 클라이언트 '알드라이브'입니다. 기존 알FTP에서 지원했던 FTP 접속 기능 외에, WebDAV 등 다양한 프로토콜 파일 전송을 지원합니다. S3, ucloud biz 등 대중화된 서비스도 알드라이브에서 한번에 편리하게 접속해 사용할 수 있습니다." 라고 합니다. 즉, 기존의 알FTP대신 클라우드 환경에도 대응할 수 있게 새 제품으로 리모델링 한 것이다.

알드라이브 v1.0 beta 다운로드

주요 기능 중에 눈에 띄는 것은 기존 알FTP에서 부족했던 여러 프로토콜을 지원한다는 점, 그리고 다중전송과 특히 개인적으로 맘에 드는 사이트맵 가져오기 기능이 있다. 사이트맵 가져오기 기능을 통하면 알FTP사용자나 파일질라 사용자도 아주 쉽게 알드라이브로 옮겨올 수 있다.

FTP, SFTP, WebDav 접속화면 (출처: 알툴즈 홈페이지)

사이트맵 가져오기 기능 (출처: 알툴즈 홈페이지)

드레그 엔 드롭 지원 (출처: 알툴즈 홈페이지)

http://www.altools.co.kr/Product/ALDrive_Etc.aspx

드레그앤 드롭기능은 이건 뭐 당연한 기능인데.. (드레그앤 드롭기능 이거 다른 서버로 복사하는 기능이네요. 꽤 편리하고 좋습니다.) 그런데 캡쳐 화면도 좀 성의 없어 보이네요.. 차라리 안 넣었으면 좋았을 뻔 했네요. 아직 베타라서 그런가? 이미지도 다 깨지고 뒤에 배경 글씨도 비치고 화살표도 삐뚤하고.. ㅋㅋ 앞으로 정식버전이 나오면 안내페이지도 더 좋아질 것이라고 기대합니다.

아무튼 그 동안 안티도 많긴 했지만 대다수 사용자에게 편하게 PC를 사용할 수 있도록 많은 혜택을 주었던 이스트소프트의 새 작품이니만큼 더 발전하기를 기원해봅니다. ^^

맥스무비가 티켓링크를 인수했다. 나는 티켓링크가 더 큰 사이트 인줄 알았는데 맥수무비가 더 컸다. 맥스무비는 회원 600만 이고 티켓링크는 화원 530만이란다. 역시 공연 등등의 티켓을 포괄하는 것보다 쉽게 접할 수 있는 영화에 대상범위가 더 큰 것 같다. 공연은 비용도 그렇고 부담스러운 것이 많아 자주 이용 못하기 때문도 아닐까?

맥스무비 분할 설립 및 개인정보 이전 안내

그런데 맥스무비를 티켓링크로 상호를 바꾼단다. 아마 더 넓을 범위로 활용할 수 있는 사이트 도메인을 통해 사업확장을 꽤 하는 것 같다. 그래도 영화 사업부문은 유지해서 맥스무비로 분할 설립한다니.. 이것 또한 기대해본다. 최근 저작권 문제가 많이 이슈가 되고 있고 개인 인식이 많이 바뀌고는 있지만 아직 불법으로 다운로드 받는 경우도 많은 것 같다. 나는 개인적으로 구글 무비등과 같이 싼 가격에 쉬운 접근성으로 접근하여 불법 사용자가 되는 일을 막아줬으면 좋겠다. 개인의 인식도 중요하지만 효과적인 시장과 합리적인 가격도 중요한 것 같다.

간만에 주말에 영화 한편 볼까? ^^

드림시큐리티에서 생년월일과 휴대폰 기반 본인확인 서비스를 오픈 했다. 드림시큐리티는 연말정산 사이트 들어가면 이상한 보안 프로그램들을 잔뜩 까는데 그 중에 하나가 드림시큐리티에서 만든 거다. 개인적으로 지인을 통해 약간 아는 회사라 서비스 오픈 했다는 뉴스에 특히 관심이 갔다. 요지는 정보통신망 법에 의해 주민번호의 수집이 제한되니까 이제 휴대폰하고 생년월일로 본인인증을 하라는 거다.

그런데 나는 이 서비스에 대해 실질적인 필요성에 대한 의문이 생긴다. 본인인증 자체가 왜 그렇게 많이 필요한 것인가? 우리나라만 유독 사이트 가입하려고 하면 주민번호, 공인인증서 등 수많은 플러그인 설치(결국 실패하는 경우도 다반사) 가 필요한 것일까?

http://www.mobile-ok.com

몇 년 전에 우리나라가 IT선진국이기 때문에 해외 어떠한 나라도 이러한 실명인증 문제를 겪어보지 않았고 우리가 선구자적으로 문제를 해결하고 있다는 기사를 봤다. 지금은 어떠한가? 우리는 IT선진국 맞나? 내 생각에는 이 모든 문제들이 몇 년 전이나 지금이나 우리가 IT 선진국이라는 잘못된 분석에서 모든 것이 시작되지 않았나 싶다. 우리는 결코 IT 선진국이 아니다…..

100만건 이상 개인정보 보유 사업자는 망 분리를 의무적으로 해야 하는 법안이 2월 18일부터 시행되었다. 이에 따라 여러 회사들이 망 분리를 하고 있고.. 실제로 우리 회사에서도 이미 망 분리해서 작업하고 있다. 우리는 물리적 망 분리를 하고 있는데 이거... 여간 불편한 게 아니다. 개발 따로 배포 따로.. 인터넷 따로 참 힘들다.

http://www.etnews.com/news/computing/solution/2724285_1476.html

이 기사에서는 망 분리도 3가지 종류가 있다고 구분하고 있는데 논리적, 물리적, VDI 기반이 그것이다. 논리적은 소프트웨어를 통해서 한다는 것 같고 제일 많은 기업들이 여기 참여하고 있다. 하지만 소프트웨어의 결함도 무시 못하는 것이다.. 완전한 보안은 어렵지 않을까 라고 생각한다. (이견 있으신 분은 말씀해주세요) 또한 물리적은 경험상 좀 불편하다. 결국 클라우드 시대를 맞이한 지금 우리가 가야 할 길은 VDI라고 생각한다. 그렇게 되면 개인 pc도 고비용의 장비일 필요도 없어진다. 전력 소모도 줄어들고 결국 환경도 보존하고 이게 바로 그린컴퓨팅이다. 빨리 이런 시대가 왔으면 좋겠다.

http://www.dincloud.com/blog/why-dincloud-is-best-vdi-solution

삼성과 인텔이 공동 개발중인 모바일 OS 타이젠 2.0 sdk가 배포되었다. 타이젠은 웹 또는 네이티브 코딩이 가능한 모바일 플랫폼인 것 같다. 아래 전체 구조에서 보듯이 리눅스 기반이고 그 위에 안드로이드와 같은 코어엔진들이 올라가 있고 이런 서비스를 가지고 웹 또는 네이티브 프레임웍으로 애플리케이션을 만들 수 있는 것이다. 네이티브는 c,c++ 로 작성이 가능하다. 플랫폼 SDK는 현재는 ubuntu에서만 설치 가능하다.

https://developer.tizen.org/downloads/sdk

아래 스샷이 이번에 공개된 타이젠 2.0의 모양이다. 특이 둥근 아이콘 이 인상적으로 기억이 남는다. 어찌 보면 안드로이드와도 비슷해 보이기도 하다. 또한 5월 22~24일에 미국 센프란시스코에서 타이젠 2013 컨퍼런스도 한다. 꼭 가고 싶으신 분은 신청해도 된다.

https://www.tizen.org/events/tizen-developer-conference/2013

대충 본 느낌은 안드로이드하고 거의 유사해 보인다. 안드로이드에 폰갭과 같은 하이브리드 플랫폼이 합쳐진것 같은 느낌이랄까? 또한 안드로이드는 Java를 사용해서 라이선스에 문제가 있었던 반면 타이젠은 그 문제를 해결한 것으로 보인다. 아무튼 삼성에서 주도적으로 하는 것이니만큼 잘됐으면 좋겠다. 국내 개발자 일자리도 늘리고 처우도 개선하고.. 오케?

2012년도 스마트폰OS 출하량 및 정유율, 역시 안드로이드와 아이폰이 대부분 점유, 출하량에서도 높은 비중을 차지한다. 이제 시장은 거의 양분체제라고 봐도 될듯하다. (윈도우 폰의 성공은… 아마 저 멀리로… ) 안드로이드의 출하량의 대부분이 삼성이 이룩한 결과라는 것이 어떤 면에서는 고무적인 반면 삼성 이외의 벤더들은 차지하는 비중이 거의 한자리 수라는 점에서는 우려할만한 결과이기도 하다.

사업자등록번호, 법인등록번호 조회

http://dart.fss.or.kr/dsae001/main.do

위 링크에서 대충 누루다 보면 나온다.

이런.. 이름따라 포스팅도 날랑날랑이군아. ㅋㅋ

난 어째서 남에 회사 법인번호와 사업자 번호가 필요 했을까.

2013년 2월 18일 월요일에 플레시 플레이어가 업데이트 되었다. 예전에 업데이트 후 바뀐 기능 때문에 곤란했었던 적이 있어서 변경 내용을 확인하지 않을 수가 없었다. 자세한 릴리즈 내용은 아래 링크에서 확인할 수 있다.

http://labsdownload.adobe.com/pub/labs/flashruntimes/shared/air3-6_flashplayer11-6_releasenotes.pdf

주요 업데이트 사항은 다음과 같다.

- Mac Retina (hiDPI) display support for Adobe AIR applications

MAC에서의 레티나 해상도를 지원한다는 내용이다.

- Full Screen Permission Dialog UI Improvement

전체 화면일 때 다이얼로그가 가운데 위치하도록 바꿨단다

- Graphics Data Query

Display object와 vector 데이터를 런타임 시 읽을 수 있게 했단다.

- Multiple SWF Support

iOS AOT모드? 에서 여러 SWF를 로드할 수 없었나 보다. 가능하게 되었다.

- Exclude devices from requestedDisplayResolution tag

이 태그를 이용해서 특정 해상도를 지원하지 않는다는 것을 써줄 수 있다.

- File API Update

preventBackup 속성을 표시할 수 있다는데 iOS관련된 내용인 것 같다.

- Stage3D Separate Sampler State

텍스쳐 셈플링 세팅을 변경할 수 있는 방법이 추가되었다.

월급쟁이인 나에게 13월의 월급인 연말정산 환급금은 달콤한 선물이다.

하지만 추가 납부 해야한다면 더이상 달콤하지 않을테지만 말이다.

얼마나 돌려 받게 될런지 아님 추가 납부를 해야 될런지 알려면 아래와 같이 확인 해 볼 수 있다.

단..

국세청이 회사들 한테서 자료를 받는 기한이 3월 12일 까지 임으로 국세청에서 계산후 조회 가능 하게 될 때 까지는 시간이 좀 걸린다는거..

머 작년도 꺼라도 확인 해 보쟈!!

http://www.hometax.go.kr/home/eaeehpe7.jsp

위 사이트로 접속후

세금신고 내역조회 > 4. 지급명세서 를 클릭!!

(공인인증서 등을 이용하여 로그인 필요함!!)

귀속연도(작년에 일해서 번 돈을 신고하고 나는 얼마를 세금으로 내면 되겠소? 라고 하는거 임으로.. 귀속년도는 현 시점에선 작년이 된다)를 선택하고.. (2012년 연말정산을 신청한 상태 임으로 2012 선택 - 3월 12일 이후 가능!! 대략 4월 말에나 가능;; )

서식은 근로소득에 관한 내용임으로 근로소득(월급쟁이라면 내가 일 해서 번 돈에 대한 소득을 신고 한 것임으로 근로소득!!) 선택!!

원천징수 영수증 보기에서 차감징수금액 항목의

금액이 '-'로 표시 되었다면 환급 (야호!! ^0^/)

아니면.. 추가 납부 입니다. (엉엉T-T)

잘못 신고된 부분이 있을 경우 5월에 정정 가능 합니다!!

너무너무 고민하고 바라보다 찾은 글 멋있다 이런 토론한 사람들..

스크롤 압박 주의!!

* 네이버 블로그에 자바 빈즈에 대한 토론 내용이 있어 올립니다.


딱히 결론이 있는 내용은 아니지만 읽어볼만한 내용입니다.

개인적으로는 Map을 선호합니다.


1. 개발이 편하다. VO를 사용하면 클래스가 너무 많아집니다.

2. VO가 성능이 좋다고 하는데??

- 과연그럴까요??
- VO를 이용하려면 요즘 프레임워크들은 자동화를 위해 리플렉션을 사용하게 됩니다. 빠를까요?
상황에 따라 다를것이니 검증은 본인이.. ^^


예를 들면 Request로 받은 값을 VO에 세팅하기위해 첫번째 리플렉션을 사용합니다.(날코딩이 아닌 잘 설계된 프레임워크 사용시)

ibatis를 거치며 쿼리를 날리기 위해 2번째 리플렉션을 사용합니다.

그리고 결과 데이터를 담기위해 3번째 리플렉션을 사용합니다.

또한 UI를 X-Internet등을 사용한다면 혹은 UI에 필요한 데이터 형식으로 변환되야 하는 경우

여기서 다시한번 4번째 리플렉션이 사용됩니다.



3. 자바빈즈가 표준이다?

- 아래 내용을 읽어보면 알겠지만, 디펙토표준 정도로 여겨지는 것이 대세인듯합니다.

- 또한 DTO로 Map도 이미 디펙토표준으로 여겨진다는...

- 많은 Framework에서 Map을 DTO로 사용가능하게 되어있습니다.



* 만약 내가 프로젝트를 한다면

- 순수 JSP라면 VO 사용을 한번 고려해 보겠습니다.

- 그렇지 않다면 Map을 사용할것입니다.(자사의 LData는 Map 이죠)

- 모델러와 의견 일치가 안된다면??? 아래 내용을 근거로 제시하고 다시한번 토론해 보시길...





================================================================================================

자바빈즈에 대한 토론(강추!!) JAVA Family / Programming

2006/02/16 00:28

복사 http://blog.naver.com/emilio19/40022016140

제목 : beans에 대해...
글쓴이: 손님(guest) 2004/11/12 17:03:29 조회수:2232 줄수: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 조회수:530 줄수: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 조회수:512 줄수: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 조회수:270 줄수: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 조회수:154 줄수: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 조회수:236 줄수: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 조회수:193 줄수: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 조회수:224 줄수: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 조회수:98 줄수:13

웹플밍에서 데이터성 클래스등의 필드에 대한접근을 getter setter로해봤자..
개발시간만 늦어진다고 생각합니다...

일단 이런 클래스는 재활용같은건 기대도 할수없으며 getter setter통해서 접근할
이유도 별로 없습니다...단순히 화면에 한번뿌리는 역할등인데..굳이 공들여
메소드를 만들 이유는 없는거지요..

저같은경우 이런 일회성(?) 에 가까운 기능을 하는 클래스들의 필드는 상당수
public로 처리하고있구요...

공통컴퍼넌트와같이 외부의 다른사람도 쓸지모르는 클래스의 경우엔..
필드접근을 setter/getter를 통해서 하게합니다....

제목 : Re: 필요한 곳에서만 getter/setter를 사용하는 것이 좋겠죠
글쓴이: 윤남영(skywatch) 2004/11/17 01:35:49 조회수:195 줄수: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 조회수:569 줄수: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 조회수:174 줄수: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 조회수:133 줄수:27

여러분이 컴포넌트 표준을 만든다고 생각해보세요.
단순히 사용하는 입장이 아닌 만드는 입장에서...

결국 SUN의 입장도 이해가 갈 것입니다.
어느 누군가의 불만을 해결하면 다시 다른 누군가의 불만이 또 나올 것이므로...

그런데 데이타 전송 객체는 자바 빈 수준의 표준을 지키면서 만들수도 있고
public 필드들로만 구성되게 해서 작성할 수도 있습니다.

필요하다면 데이터와 서버로 전달되면 그 데이터로 뭘 할지
로직까지 구현해서 전달할 수도 있습니다.

다 구현하기 나름이지요.

물론 Map을 이용한 데이타 전송 객체도 그 한가지 방법입니다.
그 것은 선택의 문제일 뿐입니다.
맘에 안들면 안쓰면 되는 것이지요.

왜냐하면 제각각 장단점을 가지고 있어서
자신에게 맞고 편리한 것을 선택하면 그 것이 자신에겐 최선의 선택인 것입니다.

그렇다고 자신이 선택하지 않은 다른 것을 나쁘다고만 할 수는 없는 것이지요.

ps:
그런데 Map을 상속받아 구현하는 것보다 위임으로 작성하는게 좋을텐데요.
사용하는 구체적 Map이 무엇이든 간에...

제목 : Re: JavaBeans의 뒤틀림
글쓴이: 이원영(javaservice) 2004/11/24 03:53:04 조회수:554 줄수: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에서 코딩되니, 그 가치와 의미를 이미 상실한
것이라 봐요.

자바서비스넷 이원영

Download JavaBean_전략보고서.doc (830976 Bytes) JavaBean_전략보고서.doc (830976 Bytes)

제목 : Re: JavaBeans
글쓴이: 서민구(guest) 2004/11/24 09:08:16 조회수:134 줄수: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 조회수:148 줄수: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 조회수:386 줄수: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 조회수:412 줄수: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 조회수:285 줄수: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 조회수:215 줄수: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 조회수:378 줄수: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 조회수:135 줄수: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 조회수:206 줄수:18

그루비가 코드 제네레이터 역할을 하는 것은 자바의 입장이고 그루비를 하나의
언어로 본다면 접근 제한자가 없다고 할 수 있죠. 내부적으로 코드 생성을 하더라도
유저가 그루비만 본다면 상관 없는 문제입니다. 위에 예를 드신 코드의 경우는
접근 제한자의 문제라기보다 그루비의 멤버 변수가 파이썬, C#등의 프로퍼티와
유사한 개념으로 동작할 수 있다는 예로 보는 게 맞는 것 같습니다.

그리고, 이런 종류의 자동 코드 생성은 별다른 문제가 있는 구조는 아니라고 봅니다.

CodeGenerationIsaDesignSmell unless it's ActiveCodeGeneration

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
http://c2.com/cgi/wiki?ActiveCodeGeneration

p.s. 인용하기는 역시 위키가 편하군요.
----
http://youngrok.com
NHN Corp. 웹플랫폼팀

제목 : Re: 프로퍼티접근에 대한 부연설명
글쓴이: 황종훈(guest) 2004/12/02 22:15:25 조회수:145 줄수:32

예 맞습니다.
전 groovy의 필드 접근이 파이썬, C#등의 프로퍼티 접근과 유사한
뭐 그런거라는 것을 보여드리고 싶었던 겁니다.

박영록님의 "객체의 필드는 직접 접근할 수도 있고" 라는 말에 오해의 소지가 있어
올려드렸던 겁니다.
박영록님께서 바로 위에서 말씀하신대로 저 접근은 프로퍼티접근입니다.

제가 말을 다시 바꾸자면
"객체의 필드를 getter,setter없이 직접 접근하는 것처럼-public처럼-접근 할 수 있고,
필요에 따라 getter,setter을 두어 프로퍼티 접근에 부가적인 기능을 지원할 수 있다."
뭐 이정도 되겠습니다.

박영록님께서는 이 사실을 알고 계신다 하더라도
읽으시는 분이 오해할 소지가 있어 올린 것 뿐입니다.
(특히 '자바'만 접하신 분에게)


'내부적으로 코드 생성해서 문제'가 있다고도,
'접근 제한자의 문제'라고도,
'자동 코드 생성은 별다른 문제가 있다'고도 하지 않았습니다.
지금까지 박영록님께서 말씀하시고자 하는 바도 다 알겠고,
전부 다는 아니지만 저도 생각했던 부분이며 동의하고 있습니다.
문제라고 말씀하시며, 굳이 위키까지 인용 안하셔도 됩니다.


반론이라기보다 오해의소지가 있는 것을 추가설명했다고 생각해 주시면 감사하겠습니다.


------
by 이즌해

1. 자신의 기술craft에 관심과 애정을 가져라.
소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?

2. 자신의 일에 대해 생각하면서 일하라!
자동 조종 장치를 끄고 직접 조종하라. 스스로의 작업을 지속적으로 비판하고 평가하라.

3. 어설픈변명을만들지말고대안을제시하라.
변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고 말하지 말고, 무엇을 할 수 있는지에 대해 설명하라.

4. 깨진 창문을 내버려두지 말라.
눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.

5. 변화의 촉매가 되라.
사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.

6. 큰 그림을 기억하라.
주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 말라.

7. 품질을 요구사항으로 만들어라.
프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라.

8. 지식 포트폴리오에 주기적으로 투자하라.
학습을 습관으로 만들어라.

9. 읽고 듣는 것을 비판적으로 분석하라.
벤더, 매체들의 야단법석, 도그마에 흔들리지 말라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.

10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.

11. DRY(Don’t Repeat Yourself)-반복하지 마라
어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현을 가져야 한다.

12. 재사용하기 쉽게 만들라.
재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

13. 관련 없는 것들 간에 서로 영향이 없도록 하라.
컴포넌트를 자족적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

14. 최종 결정이란 없다.
돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.

15. 목표물을 찾기 위해 예광탄을 써라.
예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해준다.

16. 프로토타입을 통해 학습하라.
프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다.

17. 문제 도메인에 가깝게 프로그래밍하라.
사용자의 언어를 사용해서 설계와 코딩을 하라.

18. 추정을 통해 놀람을 피하라.
시작하기 전에 추정부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.

19. 코드와 함께 일정도 반복하며 조정하라.
구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀히 조정하라.

20. 지식을 일반 텍스트로 저장하라.
일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. 일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.

21. 명령어 셸의 힘을 사용하라.
그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

22. 하나의 에디터를 잘 사용하라.
에디터를 마치 손의 연장延長으로 자유자재로 다루어야 한다. 여러분이 사용하는 에디터는 설정을 바꿀 수 있고, 확장가능하고, 프로그램 가능해야 한다.

23. 언제나 소스코드 관리 시스템을 사용하라.
소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

24. 비난 대신 문제를 해결하라.
버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.

25. 디버깅을 할 때 당황하지 마라.
숨을 깊게 들이 쉬고, 무엇이 버그를 일으키는지 ‘생각하라!’

26. ‘select’는 망가지지 않았다.
OS나 컴파일러의 버그를 발견하는 일는 정말 드물게 일어나며, 심지어 써드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장 크다.

27. 가정하지 마라. 증명하라.
진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.

28. 텍스트 처리 언어를 하나 익혀라.
여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 만들지 않는가?

29. 코드를 작성하는 코드를 작성하라.
코드 생성기는 생산성을 증가시키며 중복을 막는 일에도 도움이 된다.

30. 완벽한 소프트웨어는 만들 수 없다.
소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라.

31. 계약에 따른 설계를 하라.
코드가 실제로 하기로 한 것을 문서화하고 검증하기 위해 계약을 사용하라.

32. 일찍 작동을 멈추게 하라.
보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.

33. 단정문을 사용해서 불가능한 상황을 예방하라.
단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.

34. 예외는 예외적인 문제에 사용하라.
예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.

35. 시작한 것은 끝내라.
가능하다면, 리소스를 할당한 루틴이나 객체가 해제도 책임져야 한다.

36. 모듈간의 결합도를 최소화하라.
디미터 법칙을 적용하고‘부끄럼 타는shy’ 코드를 작성해서 결합이 생기는 일을 피하라.

37. 통합하지 말고 설정하라.
애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 말라.

38. 코드에는 추상화를, 메타데이터에는 세부 내용을.

프로그램은 최대한 일반화해서 만들고, 세부 사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.

39. 작업흐름분석을통해동시성을개선하라.

사용자의 작업흐름이 허용하는 동시성을 최대한 활용하라.

40. 서비스를 사용해서 설계하라.

서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.

41. 언제나 동시성을 고려해 설계하라.

동시성이 가능하도록 설계하면, 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.

42. 모델에서 뷰를 분리하라.
애플리케이션을 모델과 뷰의 관점으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라.

43. 칠판을 사용해 작업흐름을 조율하라.
참여하는 요소들의 독립성independence과 고립성isolation을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.

44. 우연에 맡기는 프로그래밍을 하지 말라.
정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 말라.

45. 여러분의 알고리즘의 차수를 추정하라.
코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.

46. 여러분의 추정을 테스트하라.
알고리즘의 수학적 분석이 모든 것을 다 알려주지는 않는다. 실제 대상 환경에서 코드의 수행 시간을 측정해보라.

47. 일찍 리팩터링하고, 자주 리팩터링하라.
정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.

48. 테스트를 염두에 두고 설계하라.
코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.

49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.

가차 없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 만들지 말라.

50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.

마법사는 엄청난 양의 코드를 만들 수 있다. 그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.

51. 요구사항을 수집하지 말고 채굴하라.
요구사항이 지면에 놓여져 있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치政治의 지층들 속 깊이 묻혀 있다.

52. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.

53. 구체적인 것보다 추상적인 것이 더 오래간다.

구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다.

54. 프로젝트 용어사전을 사용하라.
프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.

55. 생각의틀을벗어나지말고, 틀을찾아라.

해결이 불가능해 보이는 문제와 마주쳤을 때, 진짜 제약 조건을 찾아라. 스스로에게 이렇게 물어보라. ‘정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?’

56. 준비가 되었을 때 시작하라.
여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 말라.

57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.

명세의 나선에 빠지지 말라. 언젠가는 코딩을 시작해야 한다.

58. 형식적 방법의 노예가 되지 마라.
여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고, 맹목적으로 어떤 기법을 채택하지 말라.

59. 비싼도구가더좋은설계를낳지는않는다.
벤더들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 말라. 도구 자체의 장점만 갖고 판단하라.

60. 팀을 기능 중심으로 조직하라.
설계자와 코더를, 테스트 담당자와 데이터 모델 담당자를 분리시키지 말라. 코드를 만드는 방식에 맞춰 팀을 만들어라.

61. 수작업 절차를 사용하지 말라.
셸 스크립트나 배치 파일은 똑같은 명령을, 똑같은 순서로, 어느 때라도 반복해서 실행해준다.

62. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.

매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.

63. 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.

뭐 더 할 말 있나?

64. 파괴자를 써서 테스트를 테스트하라.

코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.

65. 코드 커버리지보다 상태 커버리지를 테스트하라.

중요한 프로그램 상태들을 파악해서 테스트하라. 단지 많은 코드 줄 수를 테스트 범위 안에 넣는 것만으로는 충분하지 않다.

66. 버그는 한 번만 잡아라.
인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 만들라.

67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라.

코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고, MVC 모델을 쓰고, 자동 생성을 이용하고 등등.

68. 문서document가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라.

코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 힘들다.

69. 사용자의 기대를 부드럽게 넘어서라.
사용자들이 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

70. 자신의 작품에 서명하라.
옛날 장인들은 자신의 작업 결과물에 서명하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

출처: http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200505180011

[단독] 공인인증서 유출 수백 개?.."수십 만건 유출 우려"

http://news.mtn.co.kr/newscenter/news_viewer.mtn?gidx=2013021316090266786

2013년 02원 13일 파밍을 이용해 공인인증서가 유출되었다는 내용의 기사이다.

파밍(Pharming)은 새로운 피싱 기법 중 하나이다. 파밍(pharming)은 사용자가 자신의 웹 브라우저에서 정확한 웹 페이지 주소를 입력해도 가짜 웹 페이지에 접속하게 하여여 개인정보를 훔치는 것을 말한다. 파밍 범죄자가 웹 브라우징의 속도를 향상시키기 위해 인터넷 서비스제공자가 지정한 인터넷 주소정보에 접근할 수 있는 권한이 있거나 ISP회사의 서버에 결점이 있는 소프트웨어가 존재하여 사기꾼이 해킹으로 이 인터넷 주소를 변경시킬 수 있다면 가능하다.

http://ko.wikipedia.org/wiki/%ED%8C%8C%EB%B0%8D

이제 공인인증서를 위한 또 다른 보안 이 필요할 때인가? 그냥 비밀번호를 안전하게 관리하고 자주 바꾸는 게 제일 좋아 보인다. 점점 더 불편해질 뿐...

http://article.joinsmsn.com/news/article/article.asp?total_id=9043267

http://www.microsoft.com/ko-kr/download/details.aspx?id=36772

MS에서 'Microsoft Word를 위한 아래아 한글 문서 변환 도구'를 발표했다. 그 동안 회사에서 한글 프로그램이 없어서 편집은 당연히 못하고 뷰어만 가능했다. 최근에 한글 뷰어 마저 보안 취약점이 발견돼서 사실 사용하기 꺼려졌었는데 MS에서 이런 귀중한 도구를 발표하다니 참 반갑다. 잘 동작했으면 좋겠다. 테스트로 간단한 파일을 해보니 잘 되는 것 같다.

(다운로드 페이지)

변환 샘플, 잘 된다. ^^

왠지 이국적인 팬. 오래 전에 여행 갔을 때 승무원이 준 팬을 최근에 발견했다. 거의 쓰지 않아 새것 같다. 더군다나 주위에 독일어가 쓰여져 있어서 왠지 이국적이다. 또 여행가고 싶다. ㅜㅜ 또 갈 수 있겠지? 오늘은 이 팬으로 마음껏 써보자! 쓱쓱~

2013년 올해는 하는 일마다 모두 대박나라~!! 화이팅~!