티스토리 툴바

Daum
Tistory
로그인
블로그 이미지
카라크라스

Leon.Kim의 공부하는 블로그입니다. mail - kalaklas@gmail.com twitter - @kalaklas

Rss feed Tistory

Java에 해당되는 글 34건

Java/DesignPattern 2011/02/08 11:20

inheritance and composition on Java

inheritance and composition on Java

 예전에 디자인 패턴 공부하기에 앞서 머리속에 잘 정리되어 있어야할 필수 요소로서
상속, 합성에 관한 정리가 필요했다.

GoF 에 보면 두번째 객체 지향 설계의 원칙으로
Favor object composition over class inheritance.

상속을 남발하지 말고 합성에 좀 더 의존하여 설계할 때 더 reusable하다는 결론을 내기위한 첫구문이었다;;(?)

아래처럼 정리했었는데 . . . GoF에 생성패턴, 행동패턴만 살펴 보고 거의 1년여째 미루고 있다;;;
공부 좀 해야하는데;


상속?
클래스 상속
- 클래스는 정의된 객체의 구현을 바탕으로 한다
 (코드와 내부 표현 구조를 공유하는 메커니즘)
인터페이스의 확장이 목적이 아니라 부모 클래스 구현의 재사용이 목적
->컴파일타임에 객체가 정적으로 정의됨
있는 클래스를 빨리 재활용해 새로운 클래스를 정의하려는 목적
 
인터페이스 상속
- 어떤 객체가 다른 객체 대신에 사용될 수 있는 경우를 지정하는 매커니즘
->런타임에 서브타입의 객체로 대체가 가능함(동적바인딩이 가능)

상속 ,합성: 객체 지향에서 기능의 재사용을 위해 구사하는 가장 대표적인 기법
 
상속 : 부모클래스의 구현을 상속받아 한 클래스의 구현을 정의하는것, White-box reuse(상속을 받으면 부모클래스의 내부가 자식에게 공개되므로)
합성 : 다른 객체를 여러 개 붙여서 새로운 기능 혹은 객체를 구성하는 것, Black-box reuse(내부가 공개되지 않은 상태에서 인터페이스를 통해서만 재
    사용되므로)
 
상속 
장점 : 컴파일 시점에 정적으로 클래스 구조가 정의되며, 부모 클래스의 일 부분만 재정의 가능하다.
단점 : 런타임에 상속받은 부모 클래스의 구현을 변경할수 없다
부모 클래스의 구현에 종속 적이므로 부모의 구현에 변경이 있을시 자식도 변경해야한다
 
합성 
장점 :
단점 :

'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
design pattern, pattern in java
트랙백 0, 댓글 0
Java/DesignPattern 2010/11/25 02:28

행동패턴 - 책임 연쇄 (chain of responsibility)

행동패턴
어떤 처리의 책임을 어느 객체에 할당하는 것이 좋을지, 알고리즘을 어디에 정의하는 것이 좋은지 등을 다룬다.
객체간 교류의 방법을 다루는 카테고리다.


1. 책임 연쇄 (chain of responsibility)

의도
요청하는 객체와 처리하는 객체간 의존성을 최소화하자.

요청에 반응하여 처리하는 객체를 한정하지 않고 하나 이상의 객체에 부여해
요청 객체와 처리 객체 사이의 결합도를 낮춘다.

구현
>> 요청을 처리하는 핸들러(요청을 처리하는 다수의 처리 객체 chaining해주는 객체..)

1.요청 핸들러 객체로 클라이언트가 요청을 날린다
2.1번 처리 객체가 요청에 적합한 객체가 아니면
    2번 처리객체로 요청을 전달
3.2번 처리 객체가 요청에 적합한 객체가 아니면
   3번 처리 객체로 요청을 전달




소스는 내일 +_+
marine - fire
siegeTank - fire
Wraith - fire 


'Java > DesignPattern' 카테고리의 다른 글

inheritance and composition on Java  (0) 2011/02/08
행동패턴 - 책임 연쇄 (chain of responsibility)  (0) 2010/11/25
Creational Pattern  (0) 2009/10/15
Fundamental Design Patterns  (0) 2009/08/19
책임 연쇄 패턴
트랙백 0, 댓글 0
Java 2010/05/06 11:26

Java 콘솔 활성화


Java 콘솔은 Java Runtime Environment(JRE) 버전, 사용자 홈 디렉토리, 그리고 애플릿이나 응용 프로그램 실행 도중 발생하는 오류 메시지에 대한 정보를 제공합니다. Windows 플랫폼용 Java 콘솔을 활성화할 수 있습니다.
Windows 플랫폼용 Java 콘솔 활성화
6.0, 1.5.0
  1. 시작을 누릅니다.
  2. 설정을 선택합니다.
  3. 제어판을 선택합니다.
  4. Java 아이콘을 두 번 누릅니다.
  5. 고급 탭을 누릅니다.
  6. + 기호를 누릅니다.
  7. 콘솔 표시를 선택하고 적용을 누릅니다.
Java 콘솔 활성화
Windows 플랫폼용 Java 콘솔 활성화
1.4.2
  1. 시작 --> 설정 --> 제어판을 누릅니다.
  2. "Java Plug-in" 아이콘을 두 번 누릅니다.
  3. 기본 탭을 누릅니다.
  4. 콘솔 표시를 선택하고 적용을 누릅니다.
브라우저의 Java 콘솔 보기 Internet Explorer
  1. 브라우저 메뉴 모음에서 도구를 누릅니다.
  2. "Sun Java Console"을 선택합니다.

Mozilla 및 Netscape 7.1
  1. 브라우저 메뉴 모음에서 도구를 누릅니다.
  2. 개발자 모드 --> "자바 콘솔"을 선택합니다.

>>Sun.java에서 퍼옴

'Java' 카테고리의 다른 글

Java 콘솔 활성화  (0) 2010/05/06
Java Obfuscate with ZKM  (0) 2009/10/23
key-value를 가진 File의 내용을 읽어와 Tree를 구성하여 Node에 할당하기  (0) 2009/10/15
Application 개발에 있어 ResourceBundle은 매우 유용합니다.  (0) 2009/10/15
JVM Specification 을 간단히 리뷰해 보았습니다.  (0) 2009/10/15
Java jar를 이용한 번들파일 생성과 Handling  (0) 2009/10/15
트랙백 0, 댓글 0
Java/Java Concurrency in practice 2010/03/03 01:39

쓰레드에 안전하게 클래스의 상태를 관리하기

reference : Java Concurrency in practice 

java.util.concurrent.atomic 패키지에는 숫자나 객체 참조 값에 대해 상태를 단일 연산으로 변경
할 수 있도록, atomic variable 클래스들이 이미 준비되어 있다.
java.util.concurrent.atomic
Classes  
AtomicBoolean 
AtomicInteger 
AtomicIntegerArray 
AtomicIntegerFieldUpdater 
AtomicLong 
AtomicLongArray 
AtomicLongFieldUpdater 
AtomicMarkableReference 
AtomicReference 
AtomicReferenceArray 
AtomicReferenceFieldUpdater 
AtomicStampedReference



AtomicLong등 처럼 이미 스레드에 안전하기 만들어져 있는 객체를 사용하여 
클래스의 상태를 쓰레드에 안전하게 관리 하자.



하지만, 더 많은 상태를 추가할 떄에도 그저 atomic variable을 추가하기만 해도 
충분할까?
예를들어 여러개의 AtomicRefefence 클래스를 사용해서 더 많은 상태를 추가하면,
쓰레드에 안전하게 클래스의 상태가 유지되면 기대대로 동작할까?

그렇지 않다


상태를 일관성 있게 유지하려면 관련 있는 변수들을 하나의 단일 연산으로 갱신해야
한다.
 이것을 보장하기 위해 java에서 synchronized 라는 구문을 이용한 lock을 제공한다.
(코드 보호 블럭을 지정해주는 . . . . )

다음에 계속 . .

'Java > Java Concurrency in practice' 카테고리의 다른 글

쓰레드에 안전하게 클래스의 상태를 관리하기  (0) 2010/03/03
트랙백 0, 댓글 0
Java/Effectice Java 2010/02/28 02:53

h50~52

h50. 다른 타입을 쓸 수 있는 곳에서는 String 사용을 피하자.

h51. 문자열 굘합의 성능 저하를 주의하자.
문자열 결합 연산자 (+) 를 n개의 문자열에 반복 사용하면 n의 제곱에 비례하는 시간이 
소요 된다.

String이 immutable객체 이기때문에 그런거당

a = a객체
a + b = a, b, ab객체
a + b + c = a, b, c, ab, abc객체
a + b + c + d = a, b, c, d, ab, abc, abcd객체
.
.
.
.
원하는 성능을 얻으려면? 
StringBuilder를 사용하자.
.
.
StringBuilder b = new StringBuilder(numItems()* WIDTH);
for(int i = 0; i < numItems(); i++){
b.append(lineForItem(i));
}

return b.toString();
.
.




52, 객체 차모는 그 객체의 인터페이스 타입으로 하자.
인터페이스를 객체의 타입으로 사용하는 습관을 들이면, 프로그램이 훨씬 유연해진다.

List<Leon> leon = new Vector<Leon>();
위 처럼 인터페이스를 객체의 타입으로 사용하면,
구현체(클래스)를 바꾸고 싶을때, 아래 처럼 new 다음의 생성자 이름만 변경하면 된다.


List<Leon> leon = new ArrayList<Leon>();


만약에 객체를 참조하기 위한 적합한 인터페이스가 없다면?
필요한 기능을 제공하는 클래스 상속 구조에서 가장 덜 특화된 수퍼 클래스를 객체 참조 타입으로 사용하자.

'Java > Effectice Java' 카테고리의 다른 글

h50~52  (0) 2010/02/28
h45 ~ 49  (0) 2010/02/19
h38 매개 변수가 유효한지 검사하자.  (0) 2010/01/26
h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
트랙백 0, 댓글 0
Java/Effectice Java 2010/02/19 01:40

h45 ~ 49

h45. 지역변수의 유효 범위를 최소화 하자. 
 지역 변수의 유효범위를 최조화 하면, 코드의 가독성과 유지 보수성을 높이고 에러의 가능성이
줄어든다.
 * 지역 변수의 유혀 범위를 최소화 하는 가장 강력한 방법은 그 변수가 최초로 사영되는 곳에 선
언하는 것이다.
* while보다는 for를 이용하여 순환자 변수로 인한 혼란을 미연에 방지하자.
* 메소드를 작고, 한가지 일에 집중하도록 만들자.



h46.for루프보다 for-each를 쓰자.
for(Element e : elements){
doSomething(e);
}
: = in

h.48 정확한 계산에는 float나 double 타입을 쓰지 말자.
정확한 계산에는 float나 double 타입을 쓰지 말자.
BigDecimal을 사용하자.



h49. 박스화 기본형보다는 기본형을 사용하자.



'Java > Effectice Java' 카테고리의 다른 글

h50~52  (0) 2010/02/28
h45 ~ 49  (0) 2010/02/19
h38 매개 변수가 유효한지 검사하자.  (0) 2010/01/26
h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
트랙백 0, 댓글 0
Java/Effectice Java 2010/01/26 02:11

h38 매개 변수가 유효한지 검사하자.

h38 매개 변수가 유효한지 검사하자.
reference : Effective Java second edition

>>들어가기
대부분의 메소드와 생성자는 자신들의 매개 변수로 전달될 수 있는 값에 제한을 둔다.
  휴효한 매개변수 값만이 전달되는지 반드시 확인 하는것이 좋다.

0. Exception을 이용하여 Exception을 발생시키는 방법으로 유효성 검사(IllegalArgumentException, IndexOutOfBoundsException, NullPointException 등)를 하자. (가장 일반적..)

1. assertion을 이용하여 매개 변수의 유효를 검사하자. 
(가정하고 있는 사실이 올바른 지 검사할 수 있도록 하기 위해서 자바 1.4에 추가된 기능이 바로 Assertion)
예> private static void sort(int i, int age){
assert 0<i;  //i가 0이하라면 AssertionError가 발생한다.
assert age > 0 : "나이는 음수가 될 수 없습니다:"+age;  //age가 음수이면 "Assertion 에러 문자열과
                                                                                       함께 AssertionError가 발생한다.
}


>> Exception in thread "main" java.lang.AssertionError
at Chap38.<init>(Chap38.java:6)
at Chap38.main(Chap38.java:24)


* java 실행시 assertion은 default가 무료로서, 그냥 run하면 AssertionError이 발생하지 않는다.
-ea는 -enableassertion의 약자임
-ea 옵션을 사용하지 않으면 assertion은 무효가 되고 assert문은 모두 무시됨

요약 : 메소드나 생성자를 작성할 때마다 매개 변수에 어떤 제약을 둘지 고민해 보고 제약을 둘때는, 문서화하고 매소드 맨앞에서 감사를 해야한다.

>>활용

'Java > Effectice Java' 카테고리의 다른 글

h50~52  (0) 2010/02/28
h45 ~ 49  (0) 2010/02/19
h38 매개 변수가 유효한지 검사하자.  (0) 2010/01/26
h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
트랙백 0, 댓글 0
Java/Effectice Java 2010/01/18 02:02

h25. 배열보다는 List를 사용하자.

reference : Effective Java second edition

>>들어가며
배열은 런타임시 타입 안전이 제공되지만, 컴파일 타입 안전은 제공되지 않는다.
제너릭은 반대로 런타임시 타입 안전이 제공되지 않으며, 컴파일 타입 안전이 제공된다.

Effective Java에서 에러는 가능한 빨리, 즉 컴파일 시점에 발견하여 해결하는 것이 가장 좋다고
반복하여 말하고 있다. 

1. Array의 경우 호환되지 않는 타입의 추가시 발생하는 문제점
Object[] objArray = new Long[1];
objArray[0] = "I'm String"; // ArrayStoreException 발생

컴파일 되지만 런타임시에 아래와 같은 예외가 발생한다.
Exception in thread "main" java.lang.ArrayStoreException: java.lang.String
at Chap25.main(Chap25.java:12)

2. List의 경우 호환되지 않는 타입의 추가시 발생하는 문제점
List<Object> who = new ArrayList<Long>();
who.add("I am String Object");

컴파일 타임에 에러가 발생한다.
- Type mismatch: cannot convert from ArrayList<Long> to  List<Object>


 위 둘중 어떠한 방법으로도 String객체를 컨테이너에 포함하기는 불가능하다.
배열을 사용하면 런타임시 에러가 발생하고
리스트를 사용하면 컴파일시 에러가 난다.
당연히 일찍 (컴파일시) 발견하는것이 좋다는 . . . 






배열과 제너릭은 근본적으로 다음과 같은 차이점을 지니고 있다.
1. 배열은 구체적이다 자신의 컨테이너에 포함될 요소의 타입을 런타임시에 알고 제약한다.
하지만 
2. 제너릭은 컴파일시에만 자신의 컨테이너에 포함될 요소의 타입을 제약하고, 런타임시에는
자신의 컴테이너에 포함될 요소의 타입을 무시한다.


* 컴파일시 보다 런타임시에 더 적은 정보를 갖는 것을 비구체화 타입 nonreifiable type이라 한다.


>>활용

'Java > Effectice Java' 카테고리의 다른 글

h45 ~ 49  (0) 2010/02/19
h38 매개 변수가 유효한지 검사하자.  (0) 2010/01/26
h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
h22. static 멤버 클래스를 많이 사용하자  (0) 2009/12/30
트랙백 0, 댓글 0
Java/Effectice Java 2010/01/12 01:16

h24. 컴파일 경고 메시지가 없게 하자.

h24. 컴파일 경고 메시지가 없게 하자.
reference : Effective Java second edition

>>들어가기
제너릭을 사용해서 프로그램을 작성하면 컴파일 경고 메시지를 많이 목격하게 된다.
unchecked cast 경고, uncehcked 메소드 호출 경고, uncehcked 제너릭 배열 생성 경고,
unchecked 변환 경고등등이다.

이러 경고 메시지는 최대한 깔끔하게 신경 써서 없애자. 그래야 코드의 타입 안전이 보장되는 것이라고 확신 할 수 있기 때문이다. 

@SuppressWarnings("unchecked") 주석으로 경고 메시지를 억제 할 수 있는데,
뭔가 확신이 없을 때는 앵간하면 쓰지 말자.

@SuppressWarnings("unchecked") 주석은 지역 변수 선언 부터 클래스 까지 다양한 범위를 커버 할 수 있는데, 최소범위로 사용하자. 예상치 못한 범위에 있는 경고까지 커버하여 문제를 양성할 수도 있기 때문이다.

@SuppressWarnings("unchecked") 주석을 이용하여 경고 메시지를 억제할 경우 꼭 주석을 달아 혼란을 최소화 하자.

'Java > Effectice Java' 카테고리의 다른 글

h38 매개 변수가 유효한지 검사하자.  (0) 2010/01/26
h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
h22. static 멤버 클래스를 많이 사용하자  (0) 2009/12/30
h20. 태그 클래스보다는 클래스 계층을 사용하자.  (0) 2009/12/29
트랙백 0, 댓글 0
Java/Effectice Java 2010/01/12 01:06

h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.

h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.

reference : Effective Java second edition



>>들어가기
이전에 제너릭타입이 등장하기 전에
List stamps = new List();
stamps.add(new Stamp());
처럼 타입 매개 변수를 주지 않고 컬렉션 타입이나 다른 제네릭 타입을 사용했다. (현재도 여전히 사용 가능하다)
그렇다고 해서 원천타입을 사용하지 말자.

stamps컬렉션에 항상 Stamp의 인스턴스가 추가된다는 보장이 없다. (억지라 생각할 수 있지만 실제 그런 상황이 많이 발생한다.)

stamps.add( new Post()); 이렇게 해도 stamps컬렉션에 Post객체는 이상없이 추가된다.

for(int i = 0; i < stamps.size();i++){
Stamp s = stamps.get(i);
.
.
.
. 
} 
Post 객체를 꺼내는 순간 에러가 발생한다.  CalssCastException 
"에러는 가능한 빨리 즉, 컴파일 시점에 발견되어야 가장 좋은데, 이런 경우 런타임에 에러가 발생하게 된다."

지금까지 쟤네들이 되는 이유는 호환성 때문이기 때문이다. 절대 비추다.(이주호환성때문에 아직 지원하는 것이다.)

List<Stamp> stamps = new List<Stamp>();
와 같이 컬렉션을 선언하면 Stamp객체만 저장될 컬렉션을 명시적으로 선언하게 되는 것이므로,
여러모로 안정성을 보장한다. (캐스팅도 필요없고 . . . 컴파일타임에 에러를 효과적으로 파악할수 있는등 . .)

List<Object> 어떤 타입의 객체도 포함할 수 있는 List를 말한다.
List<?> 언바운드 와일드 카드 타입으로 일부 미 지정 타입의 객체만 포함할 수 있는 List다.


* 원천타입을 사용하면 런타입시 예외가 생길 수 잇으므로 앞으로는 사용하지 말자

>>활용

'Java > Effectice Java' 카테고리의 다른 글

h25. 배열보다는 List를 사용하자.  (0) 2010/01/18
h24. 컴파일 경고 메시지가 없게 하자.  (0) 2010/01/12
h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
h22. static 멤버 클래스를 많이 사용하자  (0) 2009/12/30
h20. 태그 클래스보다는 클래스 계층을 사용하자.  (0) 2009/12/29
h19. 타입을 정의할 때만 인터페이스를 사용하자.  (0) 2009/12/29
트랙백 0, 댓글 0
1 2 3 4
TOTAL 16,066 TODAY 54