My Blog List

Monday, March 13, 2017

Effective Java 규칙10 toString은 항상 재정의하라

toString 값을 항상 재정의 하라고 나온다.

"모든 하위 클래스는 이 메서드를 재정의함이 바람직하다"

만약에 재정의 하지 않게 되면..
클래스이름@16진수해쉬코드 로 표현이 되는데

PhoneNumber@163b91 과 같은 사람이 인지하기에는어려움이 있다.
만약에 재정의 한다면 010-xxx-xxxx 처럼 읽기 쉽고, 명확해진다.


어떤사람들은 toString값을 파싱해서 사용하는 사람도 있다.
toString값에 이게 어떠한 값이들어있는지 주석을 달고 명시해주는것도 좋고
만약에 변동될 수 있는 사항이라면 그러한 내용을 담은 주석을 달아놓는것도 좋다.

나는 모든 클래스에 대해서 toString값을 재정의 하지 않는다.
책에서는 하라고 했는데 그냥 필요시에만 해도 여태까지 불편함없이 충분히 잘 개발해오고 debug 해왔다고 생각한다.

머 장점이라고 한다면 컬렌셕을 출력했을때 쉽게 해당 내용을 찾아볼수 있다는것??

모든 클래스 재정의는 한번 생각해볼필요가 있다.

Wednesday, March 8, 2017

Effective Java 규칙9 equals를 재정의 할때는 반드시 hashCode도 재정의해라

책의 내용이 너무 좋긴 한데 이렇게 긴글을 다 간추리기는 불가능하므로 
느낀점만 작성한다.
그리고 규칙이 띄엄띄엄 블로그에 올라올텐데
완전하게 이해가 안되는 부분은 한 사이클을 돌고 난후 두번째 읽으면서 이해가 되면 올릴 예정이다.

만약에 예를 들어

HashMap<PhoneNumber, String> 의 객체에 new PhoneNumber를 set하고
다시 똑같은 값의 객체를 생성해서 new PhoneNumber get을 하게 되는 경우

hashCode 를 재정의 하지 않은 경우 return의 null 값을 반환하게 된다.
그 이유는 각가 다른 Hash를 가지고 있기때문에 equals로 똑같은 객체라고 판단을 해도 서로 다른 hash bucket을 다이렉트로 참조 하려고 하기 때문이다.

hash code를 정의하는 알고리즘은 있을텐데...
이클립스에서는 자동으로 생성해주는것 같고..
나중에 알고리즘을 한번 읽어봐야겠다..

확실히 책을 읽으니깐 그전에 몰랐던 내용이 이해되는 부분이 많다.

Monday, February 27, 2017

Effective Java 규칙6 유효기간이 지난 객체 참조는 폐기하라

책에서는 Stack을 예를 들어 설명을 하고 있다

pop하는 부분을

return elements[--size];

이런식으로 했는데 그러면 stack 의 포지션은 size보다 더 클 수 없다.
그러면 그 이후의 값들이 전부다 무효하게 되는데..

이런 경우

elements[size] = null 로 치환 시켜주라는 이야기이다.

기존의 문제점
스택자체에서 메모리를 관리한다는 점..

null로 변경시 문제점
null point Exception이 발생할수도 있음..

캐쉬도 마찬가지인데
HashMap을 WeakHashMap이라던지
LinkedHashMap을 이용해서 구현하면 된다고 한다.

LinkedHashMap 에는 removeEldestEntry를 제공해줘서 오래된 내용을 파악하는데 도움이 된다고 함..

음... ....

머 자바 개발할때 이정도는 다 유의해서 사용하는거긴 한데..
왠만하면 자바에서 제공하는 자료구조를 이용해서 개발하는게 제일 괜찮을듯 하다.

Thursday, February 23, 2017

Effective Java 규칙5 불필요한 객체는 만들지마라

1. String 생성할때 new String("ab") 이런식으로 만들면 불필요한 객체를 생성하게 된다
차라리 String  key = "ab" 이런식으로 만들면 객체는 하나만 생성되고, 다른곳에서 사용을 하더라도 jvm 에서 객체를 생성하지 않고 동일한 객체를 사용한다.

2. Long  long autoboxing으로 primitive로 해결할 수 있는거는 굳이 Long으로 사용하지 않는다.

3. 데이터 베이스 같은 고 메모리의 객체를 사용할때는 Pool을 사용하면 성능에 좋겠지만
일반적으로는 사용하지 않는게 더 좋다. 그 이유는 (최적화된 쓰레기 수집기) 라고 번역되어있지만 이게 gabage Collector를 말하는것 같네요. 그 이유는 가벼운 객체라면 풀보다 월등한 성능도 보여지고 코드수가 간결해진다.


Monday, February 13, 2017

Effective Java 규칙4 객체 생성을 막을때느 private 생성자를 사용하라

객체 사용을 왜 막아야할까??
모든 메소드들이 정적 패턴으로 이루어져있다면..

책에서는 Math 클래스를 예를 들었다.
사실 메소드 단위의 기능들을 객체로 만들기도 애매하고. 그런경우 정적 (static) 메소드로 만드는데 어찌되었든 객체 생성을 막고싶을때 어떻게 해야하나??

클래스를 abstract로 생성한다면??? 하위클래스로 생성하면 그만이다.
생성자를 private 로 선안하면 객체 생성이 안된다

그리고 클래스 내부에서도 호출을 못하도록 예외를 던지면 객체를 생성할수 없는 class 완성

이걸 해서 머할까?? 아직은 감이 안오넹..

Effective Java 규칙3 private 생성자나 enum 자료형은 싱글턴 패터을 따르도록 설계하라 TODO

이거는 나중에 정리해야겠다

Thursday, February 9, 2017

Effective Java 규칙2 생성자 인자가 많을 때는 Builder 패턴 적용을 고려하라

다시 말하지만 내용을 요약한 부분이 아니라 이 책을 읽고 어떻게 이해를 했고 장단점이 머가 있을까라고 생각하는 나의 의견을 적는 곳이라서 참고 부탁합니다.


일반적으로 자바 빈스 패턴으로 getter와 setter를 사용하는게 일반적이지만
생성자를 만들때 인자의 개수가 많아지면 곤란한다. 그리고 그 인자 값들이 필수 값이 아니라 선택사항일 경우 인자의 개수만큼 생성자수의 개수만큼 만들어지니 복잡해진다.

만약에 개수가 A, B, C, D 4개라고 한다면 (모두 String이라고 가정한다.)

Class(A) 가 필요하겠고
Class(B) 가 필요하겠고
...
Class(A, B) 가 필요하고..
음..
불필요하게 많은 생성자가 필요하다.

Build Pattern 의 장점

  1. 한번 build를 하면 변수값들이 immutable이 된다.
  2. 내부적으로 일련번호를 만들어서 관리할수 있다.
  3. build할때마다 새로운 객체를 생성할 수 있다.
  4. 변수 입력후 반환타입이 build객체라서 객체가 유연하다.


Build Pattern 의 단점

  1. 코딩이 길어진다
  2. 귀찮다.
  3. 장점이지만 한번 빌드한 변수는 수정이 불가능하다

이 정도로 생각이 되네요.