제스처 인식을 하기 위해서 립모션에 대해서 분석했던 자료들입니다.


- 립모션에 대한 소개

- API Overview

- 립모션 API

- 평가

최종적으로 제스처 인식에는 다소 부족함을 보였지만
게임과 같은 엔터테이먼트 요소로 활용하기에는 좋은 디바이스라고 생각됩니다.

립모션이란.pptx



'유용한 팁' 카테고리의 다른 글

Leap Motion  (0) 2014.12.03
앱과 정보 보안  (0) 2014.12.03
함수의 선언과 정의의 차이점  (0) 2012.11.27
[스크랩]GPL/LGPL/MPL/BSD 라이선스  (0) 2012.09.19
오버로딩과 오버라이딩  (0) 2012.09.17
[프로그래밍] 프로세스와 스레드  (0) 2012.09.06
APP에서 일반 텍스트나 다른 데이터들을 읽기 쉽도록 모바일 디바이스에 저장하는 일은 되도록 삼가

- APP에서 어떤 유형의 데이터를 저장, 생성, 교환할 것인가를 결정

- APP에서 재사용 가능한 암호화 루틴을 몇가지 보유(AES 등). 
프로젝트 내에서 포함할 수 있도록 분리된 라이브러리 형태로 유지

- 각각의 애플리케이션에서 다른 키를 생성한다.
길고 예측하기 어려운 비밀 키 생성 알고리즘을 통해 키를 생성

- 데이터를 생성하거나 저장할 때 암호화한다.


'유용한 팁' 카테고리의 다른 글

Leap Motion  (0) 2014.12.03
앱과 정보 보안  (0) 2014.12.03
함수의 선언과 정의의 차이점  (0) 2012.11.27
[스크랩]GPL/LGPL/MPL/BSD 라이선스  (0) 2012.09.19
오버로딩과 오버라이딩  (0) 2012.09.17
[프로그래밍] 프로세스와 스레드  (0) 2012.09.06

1. 선언의 형식

반환형  함수이름(매개변수들);

 

2. 정의의 형식

반환형  함수이름(매개변수들)

{

 내용;

}

 

3. 선언은 그러한 함수가 있다고 알리는 것이고 정의는 그 함수의 실제 내용을 만드는 것입니다.

4. 정의는 선언을 겸합니다.

5. 정의되어 있지 않은 함수를 선언하고 호출하는 코드가 포함된 프로그램을 빌드하면 컴파일은 됩니다만 링크 시에 해당 함수의 실체를 찾을 수 없으므로 링크 오류가 발생합니다.

6. 함수가 정의되어 있더라도 선언되어 있지 않으면 이를 호출할 수 없습니다. 이는 컴파일 오류를 발생시킵니다.

여기서 상기할 것은 정의는 선언을 겸한다고 한 것입니다.

즉, 선언 또는 정의한 곳 이후의 위치에서 해당 함수를 호출할 수 있다는 의미입니다.

예를 들면, 함수를 별도로 선언하는 것이 귀찮을 때 main 함수 위에서 함수를 정의해두고 main 함수에서 이를 호출하는 것을 보셨을 것입니다. 만약 해당 함수가 main 함수 뒤에 있다면 main 함수 앞에서 선언을 별도로 해주어야 main 함수에서 해당 함수를 호출할 수 있습니다.

 

'유용한 팁' 카테고리의 다른 글

Leap Motion  (0) 2014.12.03
앱과 정보 보안  (0) 2014.12.03
함수의 선언과 정의의 차이점  (0) 2012.11.27
[스크랩]GPL/LGPL/MPL/BSD 라이선스  (0) 2012.09.19
오버로딩과 오버라이딩  (0) 2012.09.17
[프로그래밍] 프로세스와 스레드  (0) 2012.09.06

출처http://yundarz.egloos.com/9142824


GPL
GPL(General Public License)은 MPL이 나오기 이전에 가장 널리 사용되던 공개 소프트웨어 라이선스였다. GPL은 OSS의 가장 대표적인 라이선스로 GNU 프로젝트 소프트웨어를 배포할 때 사용되는 것이었지만 이후에는 GNU 프로젝트로 시작된 것이 아닌 다른 소프트웨어에도 광범위하게 사용되고 있다.
GPL은 리차드 스톨만에 의해 만들어졌고 자유 소프트웨어 재단의 철학을 반영하고 있다. 소프트웨어를 복제하거나 유통하는데 제약은 없지만 몇 가지 조건을 만족시켜야 한다. 사용자가 소스 코드를 쉽게 사용할 수 있어야 하며 배포되는 소프트웨어에는 GNU GPL이 포함되어 있어야 한다. 그리고 쌍방향 프로그램의 경우 프로그램이 시작될 때 이를 게시해야 한다. 프로그램을 수정할 경우에는 언제, 누구에 의해 수정되는지를 명시하기만 하면 된다. 파생 제품을 만들 수 있지만 파생 제품에는 GPL이 적용되어야 한다.
GPL의 가장 큰 특징은 배포된 소프트웨어가 상업용 소프트웨어(proprietary product)로 변질되는 것을 막아주는 조항, 이른바 카피레프트 조항을 가지고 있다는 것이다. 결과적으로 GPL 소프트웨어를 결합하여 만든 소프트웨어는 반드시 GPL이 적용되어야 하므로 이른바 바이러스 효과가 일어난다. 즉 GPL은 저작권을 포기하는 것이 아니다. 만일 개발자나 기업이 GPL이 적용된 소프트웨어의 일부를 사용하여 다른 소프트웨어를 개발할 경우, 기업은 그들이 개발한 소프트웨어의 소스 코드를 공개해야만 한다. 결과적으로 소프트웨어를 제작 판매하는 기업에서는 GPL이 적용된 소프트웨어를 기피하는 문제가 있다고 할 수 있다.
GPL의 주요한 특징을 살펴보면 첫째 소스 코드뿐만 아니라 목적 코드(object code) 또는 실행 가능한 형태(executable form)로도 배포를 허락하지만, 이 경우 어떤 형태로든 소스 코드에 대한 접근이 보장되어야 한다. 둘째, 2차적 저작물이 GPL에 의해 라이선스 된다는 조건하에 코드의 변경 및 재배포를 무제한으로 허용한다. 셋째, 다른 소프트웨어와의 완전한 통합(complete integration)은 그 소프트웨어가 GPL을 수용한다는 조건하에서만 허용된다.

LGPL
이와 같은 이유로 GPL이 소프트웨어를 제작 판매하는 기업에서 사용되는 것에 제한이 있으므로 자유 소프트웨어 재단은 LGPL(GNU Lesser General Public License)을 만들었다. LGPL이 적용되는 라이브러리를 사용해도 개발된 소프트웨어는 GPL에 오염되지 않는다. 이를 만든 이유는 좋은 자유 소프트웨어 제품이 많이 사용되어 표준이 되고 독점 제품과 경쟁할 수 있도록 하기 위해서다. LGPL이 적용된 최초의 소프트웨어는 GNU C 라이브러리였다. LGPL은 GNU 프로젝트에 의해 개발된 소프트웨어와 사적 소프트웨어를 포함한 다른 소프트웨어와의 통합을 허용하기 위해 자유 소프트웨어 재단에 의해 만들어졌다. 자유 소프트웨어가 아닌 모듈과의 링크를 허용한다는 면에서 완전한 카피 레프트 라이선스는 아니라고 할 수 있다.
LGPL은 보통 라이브러리를 라이선스할 때 사용되는데, 특히 자유 라이브러리(free library)에 대응되는 상용 라이브러리가 존재할 때 사용된다. 일반적으로 소프트웨어 개발자들은 비슷한 기능의 라이브러리가 존재할 때 제한이 별로 없는 상용 라이브러리를 사용하게 될 것이고, 그렇게 된다면 자유 라이브러리는 점점 사용되지 않을 것이기 때문이다. 반면 대응되는 상용 라이브러리가 없는 자유 라이브러리를 만들었을 때는 LGPL 대신 GPL을 사용하고 있다.

MPL
MPL(Mozilla Public License)은 넷스케이프가 그들의 브라우저인 모질라의 소스 코드를 공개하는데 사용한 라이선스이다. MPL은 코드와 실행 파일을 분리하여 양자를 보완한 것이다. 코드는 공개되어야 하고 최초의 저작자에게 보완한 내용을 통지해야 한다. 반면에 실행 파일은 독점 라이선스로 배포될 수 있다. 즉 저작자의 이익을 보호할 뿐 아니라, 이 라이선스는 수정, 보완된 소프트웨어의 배포를 통한 상업적 이익을 보호 할 수 있다. 이는 적정한 가격을 요구할 수 있고, 불법 복제에 대해 제재를 가할 수 있다는 것을 의미한다. 또한 소프트웨어를 더욱 보완, 발전시키려는 개발자들의 이익을 보호할 수 있다고 생각한다. 즉 기술적으로 개선을 할 경우 코드를 보고, 수정한 후, 컴파일하여 새로운 독창적인 버전으로 재배포할 수 있다.
MPL에서 유래한 라이선스는 IPL(Interbase Public License), ISC OSPL(Open Source Public License), SPL(Sun Public License), NOSL(Netizen Open Source Lecense), OTPL(Open Telecom Public License), EPL(Erlang Public License) 등이다. MPL도 사용자에게 이후의 라이선스 계약 시 동일한 라이선스를 부과하는 카피레프트 조항을 가지고 있다는 면에서 GPL과 흡사하다. 하지만 이러한 의무가 소스 코드에만 부여된다는 점에서 차이가 있다. 다시 말하면 이용자가 원래의 프로그램에 변경을 가했거나 추가시킨 경우에 해당 소스 코드를 원래의 개발자나 공동체가 사용할 수 있도록 공표해야 하지만, 실행 가능한 바이너리 코드는 상업용 소프트웨어 라이선스를 포함한 어떠한 라이선스를 사용해서도 배포할 수 있다. MPL은 OSS(Open Sousrce Society) 그룹과 산업계와의 타협의 산물이라고 평가받는 데 특이한 점 한 가지는 프로그램의 복제 또는 배포가 특허권에 관련한 경우는 이용자에게 특허의 실시를 허용해야 한다는 점이다. 그러나 원본 코드(original code)에서 제거하거나 분리한 코드, 원본 코드의 개작 또는 다른 소프트웨어와의 결합으로 야기되는 침해에 대해서는 특허 라이선스가 허락되지 않는다.
사용자의 의무에 관하여는 MPL은 GPL의 순수한 카피레프트 라이선스와 유사하다고 할 수 있다. 만일 사용자가 의무를 불이행하는 경우에는 보장된 권리의 자동적인 소멸을 초래하게 된다. 단 GPL과는 달리 라이선스 조건 위반은 이용자의 권한을 즉각적으로 종료시키는 것이 아니라 사실 인식 후 30일 경과하면 소멸한다고 규정한다.
다음은 개발자에게 중요한 개작자의 의무에 대해 살펴보자. 개량자는 코드 개작시 취득한 저작권을 MPL하에 라이선스해야 할 의무가 있다. 그러나 그는 원 코드를 잉여할 권리는 가지지 않는다. 프로그램의 개작(modification)이 발생하면 재작자는 개작된 프로그램 소스 코드를 공개해야 하고 개작 내용(description of modifications)에 대해 문서화할 의무가 있다. 무엇보다도 MPL 적용 프로그램을 실행 버전(executable versions)으로 배포하는 자는 프로그램의 소스 코드에 대한 접근을 가능케 해야 한다. 만일 법규 또는 판례로 인하여 이용자가 준수가 불가능한 경우 이용자는 ‘가장 가능한 범위까지(to the maximum extent possible)’ MPL 조항을 준수해야 하며, 법규들이 영향을 미치는 제한(limitations)을 설명해야 한다고 하고 있다.

BSD 라이선스
BSD(Berkeley Software Distribution) 라이선스는 언제나 라이선스의 주석에 BSD가 캘리포니아 대학에서 처음 개발된 것이기에 이를 명시해야만 하는 다소 단순하고 귀찮은 의무가 기재되어 있으며 FreeBSD, X, NetBSD 등 여러 변종이 존재한다. BSD는 소프트웨어 산업과 관련하여 가장 다양하게 사용될 수 있는 라이선스라고 할 수 있다. BSD 라이선스가 적용되는 소프트웨어를 수정, 보완한 소프트웨어는 상업용 독점 소프트웨어가 될 수도 있고, BSD 라이선스로 배포될 수 도 있다. 또한 GPL로 배포될 수도 있다.
BSD 라이선스는 예컨대 아파치 웹 서버 등에 사용되는 라이선스로 사용자들에게 거의 제한을 가하지 않는 것이 특징이다. 심지어 카피레프트 조항도 없기 때문에 사적 소프트웨어 벤더들도 BSD 라이선스로 배포되는 OSS 컴포넌트를 그들의 제품에 무제한으로 사용할 수 있다. 예컨대, BSD는 X 라이선스의 변형인데 동 라이선스는 소프트웨어를 사용, 복제, 통합, 변경, 발행, 배포 및 판매할 권리를 부여한다. 다만 때때로 저작권 표기를 요구하거나 코드 변경의 날짜, 저자 및 변경목적을 요구하기도 한다. MIT 라이선스, XFee86 라이선스, X 컨소시엄 라이선스 모두 저작권과 무보증의 표시만 한다면 누구든지 무상으로 소프트웨어를 사용, 복제, 변경, 병합, 출판, 배포, 다시 라이선스 할 수 있으며 이러한 것들을 유상으로 타인에게 판매할 수 있도록 하고 있다. 이같이 라이선스 허용범위가 넓은 이유는 BSD 라이선스가 미국 정부가 제공한 재원으로 운영되었기 때문이라고 한다. X 라이선스는 소프트웨어를 사용, 복제, 변경, 통합, 발행, 배포 및 판매할 권리를 부여한다. 다만 때때로 저작권 표기를 요구하거나, 코드 변경의 날짜, 저자 및 변경목적을 요구하기도 한다.
BSD, X 라이선스, 아파치 웹 서버 프로젝트 라이선스 류의 가장 중요한 사항은 X 라이선스를 따르는 개작을 개인적으로 허가하고 있다는 점이다. 쉽게 말하면 X 라이선스를 따르는 프로그램의 소스 코드를 구해 수정한 후 소스를 공개하지 않고 판매할 수 있다. 즉, 수정한 부분에 대해서는 X 라이선스를 적용하지 않은 채로 판매할 수 있다. 반면 GPL은 개인적으로 개작한 부분은 GPL에 따라서 반드시 배포되어야 한다고 규정하고 있으며, 그에 따라 프로그램 개발자는 타인의 개발성과를 받아볼 수 있다.
BSD는 무엇보다 2차적 저작물에 대한 카피레프트 조항이 없다. 즉, 배포하거나 공표하려는 저작물의 전부 또는 일부가 양도받은 프로그램으로부터 파생된 것이라면, 저작물 전체에 대한 사용 권리를 GPL의 규정에 따라 공중에게 무상으로 허용해야 한다고 GPL이 명시한 부분이 없다. 따라서 상업용 소프트웨어 판매자들도 BSD 라이선스로 배포되는 공개 소프트웨어의 컴포넌트를 자신의 제품에 무제한으로 사용할 수가 있다. BSD 라이선스 정책을 지지하는 사람들은 GPL 라이선스가 지나치게 엄격하다고 비판하기도 한다.
BSD 지지자들은 아무런 제한 없이 소스를 공개하고, 이를 누구든지 자유롭게 재배포하고 수정할 수 있도록 함으로써 이러한 소프트웨어들이 상업적으로도 사용될 수 있도록 문호를 개방하는 편이 훨씬 더 효과적으로 자유로운 소프트웨어의 사용이라는 목표를 달성할 수 있다고 보고 있는 것이다. 그러나 GPL을 지지하는 측에서는 BSD 라이선스를 선택하는 것은 기업들이 소스를 변형하여 2차 저작물을 작성해 이에 대해 독점적인 라이선스 정책을 취할 것이며, 일반인들의 자유 사용이 제한되므로 진정한 자유 소프트웨어는 될 수 없을 것이라고 비판하기도 한다. BSD 라이선스 정책을 취하고 있는 소프트웨어 중에는 세계 웹 서버의 50% 이상에서 작동하고 있는 아파치 서버, Perl 소프트웨어, BIND, sendmail 소프트웨어와 같이 상업적으로도 많이 사용되고 있는 소프트웨어들이 많다. 그 중에서도 BSD 라이선스는 예컨대 아파치 웹 서버 등에 사용되는 라이선스로 사용자들에게 거의 제한을 가하지 않는 것이 특성이다.
이상 BSD 라이선스의 내용을 요약해 보면 다음과 같다. 오픈소스 라이선스 개념에 해당하며 GPL보다는 그 허용범위가 크다. 비자유 상용 소프트웨어와 혼합이 가능하다. 수정된 소스 코드가 원저작자에게 돌아가진 않을 수 있다. 즉, 수정한 후 소스를 공개하지 않고 상업적으로 판매할 수 있다는 점에서 GPL과 차이가 있다. 파생 저작물이 반드시 무상이어야 하는 것은 아니어서 파생물도 GPL을 따라야 하며 무상이어야만 한다고 명시한 GPL과 다른 것이다.

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

오버로딩

-한 클래스 내에서 같은 이름의 매서드를 여러개 정의하는 것을 오버로딩
-기존에 없는 새로운 매서드를 정의, 한 객체가 상황에 따란 다른 의미를 가질 수 있도록 하는 것
-매서드의 이름이 같아야 하고, 매개변수의 개수 또는 타입이 달라야 하며, 배개변수 명이 같고
리턴 타임이 다른 경우는 오버로딩이 성립되지 않는다
-오버로딩된 매서드들은 매개변수에 의해서만 구별

오버라이딩

-상속받은 매서드의 내용을 변경하는 것
-주로 서브클래스에 맞게 고쳐서 사용, 상속된 메소드와 동일한 이름, 인자를 가진 메소드를 정의하여 덫어 씌움
-오버라이드를 하기 위해서는 상위 클래스의 메소드와 이름이 같아야 하고, 매개변수 타입과 개수, 리턴타임이
같아야 하며, 상위 클래스보다 좁은 접근지정자를 사용할 수 없다.




http://blog.naver.com/elecengine?Redirect=Log&logNo=80048364012

http://ask.nate.com/knote/view.html?num=3557610

http://blog.naver.com/jsj776655?Redirect=Log&logNo=60163128190


프로세스(Process)


컴퓨터 내에서 실행중인 프로그램, 할당받은 자신만의 자원을 가지고,

CPU가 기계어 명령들을 실행함에 따라 끊임없이 변화하는 동적인 존재.

코드(Code),데이터(Data),힙(Heap),스택(Stack)


스레드(Thread)


실제적으로 명령어가 CPU를 사용하여 실행되어지는 객체의 단위.

하나의 프로세스에서 여러개의 스레드가 실행될 수 있으면 최초에 프로세스가 생성될때 메인 스레드가 생성, 이러한 스레드는 같은 프로세스에 있는 자원과 상태를 공유.(코드, 데이터, 힙의 영역을 프로세스와 공유하면서 오직 프로그램 카운터, 레지스터, 스택을 스레드별로 갖게 된다.)


차이점 : 


프로세스는 독립적으로 실행되며 별개의 메모리 영역을 차지,

스레드는 프로세스 내의 메모리를 공유해 사용할 수 있으며 프로세스 간

전환 속도보다는 스레드 간 전환 속도가 더 빠르다.


종류


메인 스레드 : 프로세스의 메인 함수로서 실행되는 스레드

일반 스레드 : 메인 스레드로부터 생성된 스레드나 스레드에서 새로 생성된 스레드


스레드 생명주기


개발자의 개발영역 : 개발자들이 직접 구현하거나 실행시켜야 하는 메서드들로 구성

안드로이드의 시스템 영역 : 안드로이드 시스템 내부 스케쥴에 따라 자동 실행되는 메서드들로 구성




new : 스레드 생명 주기의 시작으로 인스턴스는 만들어졌으나 start()되지 않은 상태를 말한다

Runnable : start()매서드 호출에 의해 스레드는 Runnable 상태로 이동한다.

Running : 스케줄러는 Runnable 풀(pool)을 체크하고 스레드는 Running상태로 이동시킨다. 이때 개발자가 작성한 run()메서드가 호출된다.

Bolcking : Sleep매서드, Wait 매서드,I/O 입출력 요청(request), 수행시 블록(Blocking) 상태로 이동한다.

Dead : Run()이 완료되면 자연스럽게 스레드는 종료된다. 이상태에서 다시 시작되는 것은 불가능하다.


스레드 동기화


동기화란?

하나의 자원(resource)을 여러 스레드가 사용할 때 한 시점에서 하나의 스레드만 허용하는 기능



* 출처 : 포씨소프트(http://www.4csoft.com)사내 게시판 

[XML]
 
* 장점 
1. 나온지 10년이 넘어 엄청나게 널리 쓰이고 있음

* 단점
1. 의미를 확인하기 위한 불필요한 TEXT(시작태그 및 닫는태그 등)가 포함 됨
2. DTO를 사용하기 위해선 반드시 파싱과정을 거쳐야 함

[JSON]
* 장점
1. 대부분의 언어별 lib지원
2. 불필요한 XML대비 TEXT가 없어 패킷용량 감소
3. 대부분의 언어의 기본 Collection type으로 바로 사용 가능 

[BSON]
* 장점
1. JSON 내용을 Binary로 변환하여 패킷용량 감소  
* 단점
1. 아직 JSON이나 XML만큼의 다양한 언어 LIB는 지원하지 않음  

[MSGPACK]
* 장점
1. JSON보다 훨씬 빠른 속도(BJON비교자료는 없지만 보다 빠름)
2. 자유로운 DTO 전환
3. 커넥션 풀 지원으로 단순 메시지 서버 구현 가능 
* 단점
1. ANDROID로하기엔 Jboss netty, SLF4J가 포함되어야 하므로 단말기는 반드시 LIB를 로드해야 함
2. IOS의 Object C는 아직 지원하지 않아 C LIB를 사용해야 함
3. WEB과 연계가 필요하다면 SESSION에 들어갈 정보에 대한 정리가 필요 함   

http://iilii.egloos.com/4457500


HashMap란? (Hap인터페이스의 한종류로써 Key와 Value 값으로 데이터를 저장하는 형태)


[참고]


1. Map인터페이스 key,value 를 매핑하는 객체로 List 형태의 조상

2. Map종류 : Hashtable, HasMap, LinkedHasMap, SortedMap, TreeMap



장점 : 


-해싱(hashing)이란 검색 방법을 사용하기 때문에 많은 양의 데이터를 검색하는데 있어서 뛰어난 성능을 보여줌.


1) 해싱 (Hashing)의 정의

- 해싱 함수 (Hashing Function)를 이용하여 레코드키에 대한 해시 테이블 (Hash Table) 내이 홈 주소  

   (Home Address)를 계산하여 주어진 레코드에 접근하는 방식이다. 

 

- 직접 접근 (Direct Access Method) 파일을 구성할 때 사용된다.

- 속도는 가장 빠르지만 충돌 현상시 오버플로 해결의 부담이 가중되며, 많은 기억 공간을 요구한다.


단점 : 


-데이터 양이 적더라도, 일정 크기의 burket을 가지고 있어야 하기 때문에, 리소스를 많이 사용하는 단점

-순서 보장하지 않음


주의 : 


-map에 데이터를 등록할 때, key값은 중복이 되지 않고, value값은 중복이 허용

-만약 중복된 key로 데이터를 삽입할 경우 해당되는 key의 데이터가 나중에 삽입된 데이터로 수정(Update)된다.


해싱(Hashing)이란?

- 레코드를 산술 연산에 의해 한 번에 바로 접근할 수 있는 기법

-  해시 함수(데이터의 저장, 위치 산출 방법)를 통해 탐색 키를 해시 테이블 주소로 변환


해싱을 사용하는 목적

알고리즘의 실행 시 소요되는 시간과 공간에 대해 적절한 균형을 제공

1)기억장소의 제한이 없을 경우 : 

키 값을 직접 기억장소의 주소로 사용하면 어떤 탐색이든지 한 번의 기억장소 접근으로 수행이 가능

2)시간에 제한이 없을 경우 :

최소한의 기억장소를 사용하여 데이터를 저장하고 순차 탐색을 수행


따라서, 해싱은 두 극단 사이(기억장소, 시간에 제한)에서 합리적인 균형을 이룰 수 있는 방법을 제공,

해싱을 사용하게 되면 가용한 기억장소를 효과적으로 사용하면서 빠르게 기억장소에 접근

A*

http://gameai.net/Article/Astar/Astar.htm


http://blog.daum.net/jty71/15645104


http://cozycoz.egloos.com/9748811

내부클래스(inner class)


1.내부클래스(inner class)란? (클래스 내에 선언된 클래스)


클래스에 다른 클래스를 선언하는 이유 : 두 클래스가 서로 긴밀한 관계이 있기 때문


내부클래스의 장점

- 내부클래스에서 외부클래스의 멤버들을 쉽게 접근할 수 있다.

- 코드의 복잡성을 줄일 수 있다.(외부에는 불필요한 클래스를 감춤)


[참고] 내부 클래스는 JDK 1.1버전 이후에 추가된 개념이다.


2.내부클래스의 종류(변수의 선언위치에 따른)와 특징


1)인스턴스클래스(instance class)


-외부 클래스의 멤버변수 선언위치에 선언, 외부클래스의 인스턴스멤버처럼 다루어짐.

-외부 클래스의 인스턴스 멤버들과 관련된 작업에 사용될 목적으로 선언.


2)스태틱클래스(static class)


-외부 클래스의 멤버변수 선언위치에 선언, 외부클래스의 static멤버처럼 다루어짐.

-외부 클래스의 static 멤버, 특히 static 메서드에서 사용될 목적으로 선언.


3)지역클래스(local class)


-외부 클래스의 메서드나 초기화블럭 안에 선언하며, 선언된 영역 내부에서만 사용


4)익명클래스(anonymous class)


-클래스의 선언과 객체의 생성을 동시에 하는 이름없는 클래스(일회용)



출처 : http://cafe.naver.com/javachobostudy.cafe

+ Recent posts