티스토리 툴바

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

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

Rss feed Tistory

Java/Effectice Java에 해당되는 글 22건

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
Java/Effectice Java 2009/12/30 00:18

h22. static 멤버 클래스를 많이 사용하자

h22. static 멤버 클래스를 많이 사용하자
reference : Effective Java second edition

>>들어가기
 nested class는 다른 클래스 내부에 정의된 클래스로서, 그 클래스를 포함하는  클래스의 지원만들 위한 목적으로만 존재해야한다.(다른 클래스에서 유용하게 생길 녀석이라면 애초부터 독립적인 클래스로서 구현하여야한다.)
 자바의 inner class는 static 맴버 클래스, static이 아닌 멤버 클래스, 익명 클래스, 지역 클래스가 있다.

얘네들을 언제 왜 쓰는지 알아보자.

1. static 맴버 클래스
가장 간단한 종류의 중첩클래스
public class Chap22Starcraft {

private int groupCnt;
static class Protoss{
}
static class Terran{
}
static class Zerg{
}
}

외곽클래스의 모든 맴버에 접근 가능한 일반 클래스라고 볼수 있다.


2. static이 아닌 맴버 클래스
public class Chap22Starcraft {

private int groupCnt;
class Protoss{
}
class Terran{
}
class Zerg{
}
}


 static 맴버 클래스와 static이 아닌 맴버 클래스의 차이점은 static이 내부 클래스에 있냐 없냐 정도의 차이다. 그렇지만 많이 다른 특징이 있다.
 static이 아닌 맴버 클래스는 외곽 클래스의 인스턴스 메소드와 필드에 참조를 얻을수 있다.(외곽클래스의 인스턴스가 있어야 static이 아닌 맴버 클래스의 인스턴싱이 가능하다)
 static맴버 클래스의 인스턴싱
Chap22Starcraft.Protoss zealot = new Chap22Starcraft.Protoss();
static이 아닌 맴버 클래스
Chap22Starcraft star = new Chap22Starcraft();
Protoss zealot = star.new Protoss();


private static맴버 클래스의 경우 외곽클래스를 나타내는 객체 컴포넌트 표현에 사용하는데 적합다. 불필요하게 외부에 객체 참조를 제공하지 않아 리소스 낭비가 없어진다.

3. 익명 클래스
익명 클래스는 말 그대로 이름이 없는 클래스를 말한다.
자신을 포함하는 외곽 클래스의 맴버도 아니다.
사용하는 시점에 선언되고 인스턴싱된다.
(어떠한 static맴버도 가질수 없다.)

4. 지역 클래스





>>활용

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

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
h18. 추상 클래스보다는 인터페이스를 사용하자.  (0) 2009/12/21
트랙백 0, 댓글 0
Java/Effectice Java 2009/12/29 01:27

h20. 태그 클래스보다는 클래스 계층을 사용하자.

h20.  태그 클래스보다는 클래스 계층을 사용하자.
reference : Effective Java second java

>>들어가기
태그 필드를 이용하여 구현된 클래스는 단점 투성이다.
enum 서언, 태그 필드들, Switch등
필요없는 메모리의 할당과 해지가 증가한다.
태그 플래스는 코드가 쓸데없이 장활하고, 에러가 나기 쉬우며, 비효율적이다.
 태그클래스를 쓰지 말고 클래스 계층을 이용하자.(서브타입...서브클래스를  . . .)

                                 abstract class Figure{ . . .}

class Circle extends Figure{ . . .}       class Rectangle extends Figure{ . . .}

위와 같이 계층관계를 사용하면,  태그 클래스 보다 코드가 간단하고 명쾌하며, 진부한 코드가 일체
포함되지 않는다. 부적절한 필드를 가지고 있지도 않고 . . . 모든 필드는 final이다.


여하튼 태그 클래스는 적합하지 않으니 계층 형태로 구성하는 것을 고려해야한다.

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

h23. 새로 작성하는 코드에서는 원천(raw) 타입을 사용하지 말자.  (0) 2010/01/12
h22. static 멤버 클래스를 많이 사용하자  (0) 2009/12/30
h20. 태그 클래스보다는 클래스 계층을 사용하자.  (0) 2009/12/29
h19. 타입을 정의할 때만 인터페이스를 사용하자.  (0) 2009/12/29
h18. 추상 클래스보다는 인터페이스를 사용하자.  (0) 2009/12/21
h16. 가급적 상속보다는 컴포지션을 사용하자.  (0) 2009/12/20
트랙백 0, 댓글 0
Java/Effectice Java 2009/12/29 00:51

h19. 타입을 정의할 때만 인터페이스를 사용하자.

h19. 타입을 정의할 때만 인터페이스를 사용하자.

reference : Effective Java second edition


>>들어가기
인터페이스는 그 클래스의 인스턴스를 참조하는데 사용될 수 있는 타입 역할을 한다.
따라서 클래스가 구현하는 인터페이스는 인스턴스로 할 수 있는 일을 나타낸다.

인터페이스는 타입을 정의할 때만 사용해야 한다.
상수를 외부에 제공하기 위해 사용하면 안된다.



>>활용

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

h22. static 멤버 클래스를 많이 사용하자  (0) 2009/12/30
h20. 태그 클래스보다는 클래스 계층을 사용하자.  (0) 2009/12/29
h19. 타입을 정의할 때만 인터페이스를 사용하자.  (0) 2009/12/29
h18. 추상 클래스보다는 인터페이스를 사용하자.  (0) 2009/12/21
h16. 가급적 상속보다는 컴포지션을 사용하자.  (0) 2009/12/20
h15. 가변성을 최소화하자.  (0) 2009/12/20
트랙백 0, 댓글 0
Java/Effectice Java 2009/12/21 01:36

h18. 추상 클래스보다는 인터페이스를 사용하자.

h18. 추상 클래스보다는 인터페이스를 사용하자.
reference : Effective Java second edition

>>들어가며
자바에서는 구현 가능 타입을 정의하는 Abstract Class, Interface 두가지 메커니즘을 지원한다.
Abstract Class : 구현 메소드를 가질 수 있다.
Abstract Class를 구현하는 클래스는 반드시 Abstract Class의 Sub class이다.(extends로서 상속 후 구현) 자바에서는 단일 상속만 가능하므로 Abstract Class를 상속하여 구현하는 Sub Class는 심한 타입의 제한이 따른다.
Interface  : 구현 메소드를 가질 수 없다.
Interface를 구현하는 클래스는 Interface에 정의된 메소드와 구현 규약을 지키기만 하면된다.(implements)

Interface는 Mixin을 정의하는데 이상적이다.
본래의 타입에 추가하여 구현 할 수 있는 기능을 제공한다는 말이다 +_+a
(본래 기능에 선택 가능한 기능을 섞는 것이 가능)
Abstract Class은 믹스인 정의에 사용이 불가능하다.(기존 클래스를 Abstract Class를 상속하려고 개조하다 보면, 엉망이 되어 Mixin하려는 의도는 어디론가 훌쩍 떠나 버릴것이기 때문에 . .다중 상속이 불가능한 자바의 특징덕에 Abstract Class는 Mixin 정의가 불가능!)

인터페이스는 비계층적인 타입 프레임워크를 구축할 수 있게 해준다.
,
,
,
,




>>활용

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

h20. 태그 클래스보다는 클래스 계층을 사용하자.  (0) 2009/12/29
h19. 타입을 정의할 때만 인터페이스를 사용하자.  (0) 2009/12/29
h18. 추상 클래스보다는 인터페이스를 사용하자.  (0) 2009/12/21
h16. 가급적 상속보다는 컴포지션을 사용하자.  (0) 2009/12/20
h15. 가변성을 최소화하자.  (0) 2009/12/20
h14, public 클래스에서는 public 필드가 아닌 접근자(accestor) 메소드를 사용한다.  (0) 2009/12/18
abstract class, Effective Java, Interface
트랙백 0, 댓글 0
1 2 3
TOTAL 16,054 TODAY 42