My Blog List

Monday, April 10, 2017

Effective Java 규칙12 Comparable 구현을 고려하라

알파벳 순서나 자연적 순서에 따르는 값의 클래스를 구현할때는
Comparable을 구현하는 것을 고려해봐야한다.

고려한다는 말은 추천한다는 말의 의미이지 꼭 써야한다는것은 아니다.


public interface Comparable<T>{
   int compareTo(T t);
}


A < B   -1
A == B  0
A > B    1

A<B 이고
B<C 인경우
A<C 이어야한다. 추이성(transitivity)

x.compareTo(y)== 0 이라고 x.equals(y) 가 참은 아니다.

int를 비교할때 대상이 음수라면
comapre로직을 고려해봐야한다.

비교 로직이 a-b > 0  이런식으로 작성할경우

int 의 max 값에서 더 큰수를 더 할 경우  즉
a = 양수 최대값이고
b = 음수면
int범위 밖의 내용에 해당하므로 음수가 반환이 된다.

Comparable은 컬렉션 객체에서 유용하게 쓰인다.

Friday, March 24, 2017

2017년 1월부터 3월까지 회고록

3월 25일 한해의 초라고 해도 맞는 말이긴 한데
지난 한 해를 돌아보면 시간인 초고속으로 흐르고 중간 중간 생각하면서 살지 않으면 
헛되이 보내버리는 시간이 많아지기때문에 갑작스럽게 글을 쓰기 시작했다.

2017년에 들어와서 공부만 놓고 본다면
1. Spark 스터디 참여 ( 2번 발표 )
2. JPA 스터디 참여 ( 1번 발표 ) 
3. Java 8 스터디 참여
4. 루씬 참여 3월~ 5일 종료예정
- 루씬을 공부한건 내 개발 인생에 있어서 가장 잘한 일중에 하나라고 생각해도 될정도로 
폭을 넓혀가고 있다

목표
4 월달에는 Spring4 스터디가 예정되어있고
5월달에는 루씬을 쭈욱 이어갈것이고
6월달에는 Solr Elastic Search 중 하나를 시작하지 않을 까 생각한다.

그리고 회사에서 서비스 개편들어가기때문에 바빠질것 같은데..

개인적으로 몇권의 책을 더 보고자 한다면

1. 클린코더,
2. Hbase
3. 조엘온 소프트웨어
4. Effective 자바
5. 머신러닝에 대해서 조금 깊게 공부를 해볼 생각이다

사실 알고리즘을 꾸준히 더 공부를 하고 싶긴 한데..
올해는 알고리즘보단 서비스를 꾸리기 위한 지식의 폭을 조금 더 넓혀볼 예정이다.


요즘 쉬는날이 없이 공부를 하지만..
알아간다는 즐거움은 날로날로 증가한다.



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 완성

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