public void given(String message, Object... args) {
....
}

이건 어디서 어떻게 쓰는 표현인고?

ellipsis (...) identifies a variable number of arguments, and is demonstrated in the following summation method.
ellipsis 라고 불리는 녀석인 것 같다.
이녀석의 특징은 메소드 등에서 동일한 객체의 파라메터(실행에 필요한 변수, 설정변수?)들을 처리할 때, 메소드마다 파라메터의 갯수를 늘려가며 설정하는 대신,
public void method(Int... args) {}  

로 설정해두면, int 형의 파라메터를 몇개를 받아도 처리가 가능하다.

간단정리 : Variable-Length Argument Lists

이 녀석의 정체를 파악해보기 위한 간단한 테스트 코드도 작성해본다.
 
package honeymon.java.study;

import org.junit.Test;
import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

public class TestEllipsis {
    @Test
    public void testEllipsis() {
	assertThat(lengthEllipsis(3, 4, 5, 6), is(4));
	assertThat(countEllipsis(2, 3, 4, 5, 6), is(20));
	assertThat(stringEllipsis("Korea", "Japan", "China"), is("Korea is Strong country."));
    }

    private String stringEllipsis(String...national) {
	String stmt = null;
	for (int i = 0; i < national.length; i++ ){
	    if("Korea".equals(national[i])) {
		stmt = national[i] + " is Strong country.";
	    }
	}
	return stmt;
    }

    private Integer countEllipsis(int... numberArray) {
	int sumresult = 0;
	for (int i = 0; i < numberArray.length; i++) {
	    sumresult += numberArray[i];
	}
	return sumresult;
    }

    private Integer lengthEllipsis(int... number) {
	return number.length;
    }
    
}
  이클립스(JDK 1.5 이상)에서 java.io.Serializable 인터페이스를 구현한 클래스를 작성할때마다 serialVersionUID를 생성하라는 경고가 뜬다. 처음에는 아무런 생각없이 무시하고 넘어갔었는데, 새롭게 프로젝트에 투입되어 선임 개발자가 작성한 소스를 보다가 도메인Domain 객체마다 선언되어 있는 serialVersionUID를 보면서 '어따 쓰는거지?'라는 궁금증이 생겨 여쭤보았다.
serialVersionUID == '분산처리 환경에서 유일한Unique 클래스라는 것을 증명하기 위한 신분증'
이라고 간략히 정의를 내렸다.

  참고사이트 : http://docs.xrath.com/java/se/6/docs/ko/api/index.html
  여기서 Serializable 인터페이스에 대한 설명을 볼 수 있다. 다만, 영어를 번역한 일어를 한글로 번역한 것이라 글의 설명이 어려운 느낌이다. 그래서 조금 순화해서 다시 써봤다.
 
  직렬화 런타임은, 각 직렬화가능Serializable 클래스에 버전번호serialVersonUID를 설정한다. 이 serialVersionUID는, 직렬화 복원 중에 직렬화객체의 송신측과 수신측이 사용하는 객체가 직렬화에 호환성이 있는 클래스인지를 확인하는 용도로 사용된다. 송신측에서 보낸 serialVersionUID와 다른 serialVersionUID를 가지는 객체를 수신측이 로드했을 경우, 직렬화 복원 중에 InvalildClassException이 발생한다.
필드명 serialVersionUID를 선언하게되면 직렬화가능Serializable 구현 클래스는, 중복되지 않는 독자적인 serialVersionUID를 가지게 된다.
※  serialVersionUID는 반드시 static final long 형으로 선언되어야 한다.

  Serializable 구현 클래스가 SerialVersionUID를 명시적으로 선언하지 않는 경우, 직렬화 런타임은 「Java(TM) 객체 직렬화 스펙」에서 설명된 것처럼, 클래스의 다양한 측면들을 근거로 클래스 serialVersionUID의 디폴트 값을 선언하여 사용할 수 있다. 그러나 가능하면 모든 직렬화 가능 클래스가 명시적인 serialVersionUID를 선언하는 것을 강력 추천(IDE에서 generate하여 선언)합니다.
  이것은, 디폴트의 serialVersionUID의 계산이, 컴파일러의 구현에 따라서 달라질 직렬화가능Serializable 클래스가 영향을 받기 쉽고, 직렬화 복원 중에 예기치않는 InvalidClassException을 발생시킬 수 있기 때문입니다. 따라서, Java 컴파일러에 상관없이 serialVersionUID의 일관성을 확보하기
위해서, 직렬화 가능Serializable 구현 클래스에서는 명시적으로 serialVersionUID를 명시적으로 선언하도록 하자.
  추가적으로, serialVersionUID의 명시적 선언에는 private 수식자를 사용하는 것을 추천합니다. 이 선언자를 사용하면, 이 속성에 대한 선언이 해당 클래스에만 적용되기 때문입니다. 즉, serialVersionUID 필드 값이 상속되지 않는다(serialVersionUID는 유일해야 한다).
  배열클래스는 serialVersionUID를 명시적으로 선언할 수 없기 때문에, 디폴트 값을 사용한다.

  IDE 내에서 serialVersionUID 선언 방법
 
1. 클래스에 Serializable 인터페이스를 구현하겠다고 선언한다.

2. Quick Fix(Ctrl+1)을 실행하고 Add generated serial versio ID(AspectJ)를 클릭한다.

3. 위의 사진처럼 private static final long serialVersionUID = 5294335241519103532L; 선언된 것을 확인할 수 있다.



나중에 추가적으로 더 알게되는 내용이나 잘못된 내용은 업그레이드 하겠습니다.
참고사항 : 개발자가 되는 법(http://wiki.kldp.org/wiki.php/HowToBeAProgrammer#s-2.1.4)

2.1.4 로그를 이용해서 디버그 하는 방법 

  로그 기록(logging)이란 정보를 제공하는 일련의 기록인 로그(log)를 생성하도록 시스템을 작성하는 활동을 말한다. 프린트 줄 넣기(printlining)는 간단한, 보통은 일시적인, 로그를 생성하기만 한다. 완전한 초보자들은 프로그래밍에 대해 아는 것에 한계가 있기 때문에 로그를 이해하고 사용해야 한다. 시스템 설계자들은 시스템의 복잡성 때문에 로그를 이해하고 사용해야 한다. 로그가 제공하는 정보의 양은, 이상적으로는 프로그램이 실행되는 중에도, 설정 가능해야 한다. 일반적으로 로그 기록은 다음의 이점이 있다.
  • 로그는 재현하기 힘든 (예를 들어, 개발 완료된 환경에서는 발생하지만 테스트 환경에서는 재현할 수 없는) 버그에 대한 유용한 정보를 제공할 수 있다.
  • 로그는, 예를 들어, 구문(statement)들 사이에 걸리는 시간과 같이, 성능에 관한 통계와 정보를 제공할 수 있다.
  • 설정이 가능할 때, 로그는 예기치 못한 특정 문제들을 디버그하기 위해, 그 문제들을 처리하도록 코드를 수정하여 다시 적용하지(redeploy) 않아도, 일반적인 정보를 갈무리할 수 있게 한다. 

  로그에 남기는 정보의 양항상 정보성과 간결성 사이의 타협으로 결정된다. 정보를 너무 많이 남긴다면 로그가 낭비적이 되고 스크롤에 가려지게(scroll blindness) 되어, 필요한 정보를 찾기 어려워질 것이다. 너무 조금 남긴다면 필요한 정보가 남지 않을 것이다. 이런 점에서, 무엇이 출력될지 설정할 수 있게 하는 것은 매우 유용하다. 일반적으로 로그에 남는 기록을 통해, 그 기록을 남긴 소스 코드의 위치, (적용 가능하다면) 문제가 되는 작업을 실행한 쓰레드, 정확한 실행 시각, 그리고 일반적으로, 어떤 변수의 값, 여유 메모리의 양, 데이터 객체의 개수 등 그 밖의 유용한 정보를 알 수 있다. 이러한 로그 생성 구문들은 소스 코드 전체에 흩어져 있는데, 특히 주요 기능이 있는 지점과 위험 부담이 있는 코드 근처에 있다. 구문마다 수준이 정해질 수 있으면 시스템의 현재 설정에 따라 그 수준에 해당하는 기록만 남기게 될 것이다. 로그 생성 구문을 설계할 때에는 어디에서 문제가 생길지 예상해서 그것을 기록으로 남길 수 있게 해야 한다. 성능을 측정할 필요성도 예상하고 있어야 한다.

영구적인 로그를 남긴다면, 로그 기록이 프린트 줄 넣기(printlining)를 대신 할 수 있을 것이고, 디버그 구문들 중에도 로그 기록 시스템에 영구적으로 추가할 것들이 있을 것이다.

로그(Logging) 과 관련된 글이 올라온 것을 보고,
급하게 내용을 찾아서 정리해본다.


  개발하는 과정에서 데이터의 처리 과정이나 발생한 오류에 대한 기록을 남기는 용도로 많이 활용하는 기능이다. 제대로 읽고 분석할 수 있는 능력을 갖춘다면, 개발실력이 한단계 향상될 것이라 믿어 의심치 않는다. 개발자가 갖춰야할 능력 중 하나는 '로그 분석' 능력!


ubuntu_logo.png

오늘(2011/03/23) 개발자분들과 번개로 만나 이런저런 이야기를 엿들은(?) 뒤, 집으로 돌아오는 길에 문득 떠올라 이렇게 첫 페이지를 시작한다.

우분투(Debian Linux 기반의 배포용 리눅스 운영체제, 무료)를 기반으로 해서 개발환경을 구축하고 사용하기가 편해진 요즘,

여기저기 흩어져 있는 내용들을 정리할 겸해서 정리를 해보려고 한다.

 

  1. Ubuntu 설치
  2. 한글 설정, 폰트 설정
  3. JDK 설정(Path 설정)
  4. eclipse, STS (IDE)설치
  5. Trac, Maven, Subversion 설치
  6. 안드로이드 개발환경 구축
  7. Python 개발환경 구축
  8. Qt 개발환경 구축

이 글은 스프링노트에서 작성되었습니다.

토비의스프링3
카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반
지은이 이일민 (에이콘출판, 2010년)
상세보기


  • 클래스 밖에서는 오브젝트를 생성하지 못하도록 생성자를 private으로 만든다.

  • 생성된 싱글톤 오브젝트를 저장할 수 있는 자신과 같은 타입의 스태틱(static) 필드를 정의한다.

  • 스태틱 팩토리 메소드(static factory method)인 getInstance()를 만들고 이 메소드가 최초로 호촐되는 시점에서 한번만 오브젝트가 만들어지게 된다. 생성된 오브젝트는 스태틱
  • 필드에 저장된다. 또는 스태틱 필드의 초기값으로 오브젝트를 미리 만들어둘 수도 있다.

  • 한번 오브젝트(싱글톤)이 만들어지고 난 후에는 getInstance()  메소드를 통해 이미 만들어져 스태틱 필드에 저장해둔 오브젝트를 넘겨준다.

   싱글톤 패턴 구현방식의 문제
 

  • private 생성자를 갖고 있기 때문에 상속할 수 없다.

  • 싱글톤은 테스트하기가 힘들다.

  • 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.

  • 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.

+ Recent posts