오예

자바라는 걸 처음 배울때는 String밖에 몰랐다. 그래서 +로 여러개의 string을 붙이곤 했다. 그러다가 누군가가 StringBuffer라는 걸 쓰는 걸 처음 봤을 때는 엄청나게 신기했다. 그래도 교육들을 때는 바쁘고 정신없어서 계속 String만 써왔는데, 알고리즘 문제를 풀다보니 성능(시간과 메모리)에 신경을 안쓸 수 가 없게 된 터라 제대로 검색해서 찾아보게 되었다. 

1. String

  String 내용이 조금이라도 바뀌거나 다른 String과 결합하게 되면 객체를 만든다. 기존 객체는 garbage collection의 대상이 된다. 새로운 객체에 새 주로를 주므로 hash code도 변한다. 이러한 과정때문에 StringBuffer와 비교해서, 시간이 오래 걸린다.

2. StringBuffer

 StringBuffer는 초기 크기를 지정해줄 수 있다. 그리고 StringBuffer에 저장하는 크기가 초과되면 자동으로 처음에 지정한 크기만큼 buffer를 늘려준다. StringBuffer는 말그래도 버퍼에서 내용물을 추가하고 삭제하기 때문에 주소값이 그대로 이고 새로운 객체를 생성하지 않는다.

3. StringBuilder 

 String으로 문자열을 +를 활용해 합치는 경우 정확히 어느 버전까지인지 모르겠는데요. 매번 String 인스턴스를 생성하는 방식이였어요. 그래서 성능상의 이슈가 많았죠. 이런 성능 이슈를 개선하기 위해 JDK 1.5 (@changhwa.oh 설명에 따르면) 버전 이후에는 컴파일 단계에서 StringBuilder로 컴파일 되도록 변경되었어요. 그래서 JDK 1.5 이후부터는 +를 활용해도 성능상에 큰 이슈는 없습니다.

StringBuffer, StringBuilder는 동기화 지원 여부입니다. 두 클래스가 제공하는 메소드는 같아요. 단, 메소드를 보면 StringBuffer는 각 메소드 별로 synchronized keyword가 존재하죠. 즉, 멀티 쓰레드 상태에서 동기화를 지원한다는 것이 다릅니다.

Slipp에서 위와 같은 글을 봤다.

일단은 여기까지만 정리한다.

논리연산자  (의미 : 또는)

a | b

a || b

무슨 차이가 있을까?

둘 다 같은 의미이다. 

하지만 (차이점) a|b 는 a, b의 값을 평가한다. 즉, a 가 참이라도 b 를 검사한다. 

a||b 의 경우 a 가 참이면 b를 검사하지 않는다. 즉 b 가 단항연산자(++ ,-- 등) 이 있어 검사할 경우와 그렇지 않을 경우에 결과에 차이가 있다. 

마찬가지로 &, && 에도 비슷하다. 

추가로 

&, |  는 논리연산자로만 사용하는 것이라 아니라 비트연산자로도 사용한다. 

a&b : 비트단위의 논리곱

a|b : 비트단위의 논리합

1. Stack

마지막에 저장한 데이터를 가장 먼저 꺼내게 되는 LIFO(Last In First Out)구조

순차적 데이터 추가/삭제하는 ArrayList적함

사용 예: ​수식계산, 수식괄호검사, undo/redo, 뒤로/앞으로(웹브라우져)

Stack st = new Stack<>();

pop(); push(); peek(); empty();

2. Queue

처음에 저장한 데이터를 가장 먼저 꺼내게 되는 FIFO구조

데이터의 추가/삭제가 편한 LinkedList적합

사용 예 : 최근 사용문서, 인쇄작업대기목록, 버퍼(buffer)

Queue q = new LinkedList();  LinkedList implements Queue?????

peek();     return null when queue is empty.

poll();       꺼내온다. 비어있으면 null

revmove(); 꺼내온다. 비어있으면 예외발생

offer();      저장한다. 성공하면 true, 실패하면 false.

isEmpty();

All the fields and methods must be static in a static method!!!

ex) public static void main(String[] args){

// fields or methods in here are static because 'main' method is used in common(?).

}

StudentInfo<T> si = new StudentInfo<T>();

=> StudentInfo<String> si = new StudentInfo<String>();
=> StudentInfo<Integer> si = new StudentInfo<Integer>();

제네릭은 사용하는 이유 : 어떤 클래스 내의 변수의 타입을 유연하게 하기 위해 Object으로 지정하면 특정한 데이터타입의 집합으로 한정지을 수가 없다. 이렇게 될 경우, type safety가 만족되지 못한다. (사용자의 실수로 클래스가 원하지 않는 데이터타입을 입력해도 컴파일단계에서는 에러가 생기지 않고 런타임에러로 생긴다. 컴파일 단계에서 이러한 실수를 잡기 위해 Generic을 사용한다.) 제네릭은 그 자체는 어떤 데이터타입도 올 수 있지만 코딩단계에서 데이터타입을 명시한다. (?)

class EmployeeInfo{

public int rank;

EmployeeInfo(int rank) {

this.rank = rank;

}

}

class Person<T, S>{  //제네릭의 데이터타입은 기본 데이터타입은 에러가 발생한다. Wrapper클래스를 대신 사용한다.

public T info;

public S id;

Person(T info, S id){

this.info = info;

this.id = id;

}

public <U> void printInfo(U info){

System.out.println(info);

}

}

public class GenericDemo{

public static void main(String[] args){

1)

Integer id = new Integer(1); //wrapper 클래스로 감싼다.

Person<EmployeeInfo, Integer> p1 = new Person<EmployeeInfo, Integer>(new EmployeeInfo(1), id);

System.out.println(p1.id.intValue()); //다시 int형으로 가져온다.

---------------------------------------------------------------------

2) 데이터타입 명시 생략가능

EmployeeInfo e = new EmployeeInfo(1);

Integer i = new Integer(10);

Person p1 = new Person(e, i);

//p1.<EmployeeInfo>printlnfo(e);

p1.printlnfo(e);

}

}

-----------------------------------------------------------------------------------------------------------

3) T의 부모 클래스(상속 혹은 구현한 클래스)를 제한

1. 컬렉션 프레임웍의 핵심 인터페이스

 Collection Framework에서는 컬렉션(데이터 그룹)을 크게 3가지 타입이 존재한다고 인식하고 각 컬렉션을 다루는데 필요한 기능을 가진 3개의 인터페이스를 정의하였다. 그리고 List와 Set의 공통된 부분을 다시 뽑아서 새로운 인터페이스인 Collection을 추가로 정의 하였다.  

1) List는 순서가 있는 데이터의 집합. 데이터의 중복을 허용한다. 

   구현클래스 : ArrayList, LinkedList, Stack, Vector 등

2) Set 순서를 유지하지 않는 데이터의 집합. 데이터의 중복을 허용하지 않는다. 

   구현클래스 : HashSet, TreeSet 등

3) 키와 값의 쌍으로 이루어진 데이터의 집합. 순서는 유지되지 않으며, 키는 중복을 허용하지 않고, 값은 중복을 허용한다. 

   구현클래스 : HashMap, TreeMap, Hashtable, Properties 등

 컬렉션 프레임웍의 모든 컬렉션 클래스들은 List, Set, Map 중의 하나를 구현하고 있으며, 구현한 인터페이스의 이름이 클래스의 이름에 포함되어 잇어서 이름만으로도 클래스의 특징을 쉽게 알 수 있도록 되어있다. 그러나  Vector, Stack, Hashtable, Properties와 같은 클래스들은 컬렉션 프레임웍이 만들어지기 이전부터 존재하던 것이기 때문에 컬렉션 프레임웍의 명명법을 따르지 않는다. Vector나 Hashtable과 같은 기존의 컬렉션 클래스들은 호환을 위해, 설계를 변경해서 남겨두었지만 가능하면 사용하지 않는 것이 좋다. 그 대신 새로 추가된 ArrayList와 HashMap을 사용하자. 

1) ArrayList : 내부적으로 array를 사용하여 구현됨. 크기를 지정하고 ㅁ

1. switch문

switch  (조건식) {
    case 값1  : 

break;

    case 값2  : 

break;

    default : 

}

 default문은 if문의 else블럭과 같은 역할을 한다고 보면 이해가 쉬울 것이다. default문의 위치는 어디라도 상관없으나 보통 마지막에 놓기 때문에 break문을 쓰지 않아도 된다. 

  조건식에 맞는 값을 위에서부터 순차적으로 찾아가며, 조건식에 맞는 case가 시작점이 되는 것이다. break문이 없으면 계속 아래 case의 명령어를 수행한다. 

 switch문 조건식의 결과는 정수 또는 문자열 또는 정수 상수만 가능하며, 중복되지 않아야 한다.

2. for문

for(초기화; 조건식; 증감식) {
    수행될 문장

}

 제일먼저 1)초기화가 수행되고, 그 다음 2)조건식이 참인 동안 3)수행될 문장 4)증감식의 순서로 계속 반복된다. 따라서 초기화 후, 조건식이 참이어야 실행이 시작된다.

3. while문 

 조건식이 참이면 블럭{}내의 문장을 수행하고 다시 조건식으로 돌아간다. 즉, 블럭 내의 문장을 모두 수행하는 동안은 조건식의 참거짓을 판단하지 않는다. 

4. do-while문

do {
} while (조건식);   <-- 끝에 ;를 잊지 않도록 주의 

 do-while문은 while문의 변형으로 기본적인 구조는 while문과 같으나 조건식과 블럭{}의 순서를 바꿔놓은 것이다. 그래서 while문과 반대로 블럭{}을 먼저 수행한 후에 조건식을 평가한다. 즉, 최소한 한번은 블럭이 수행된다.

* break문 

 switch문에서 처럼 반복문에서도 break문을 사용할 수 있는데, break문은 자신이 포함된 가장 가까운 반복문을 벗어난다. 주로 if문과 함께 사용되어 특정 조건을 만족하면 반복문을 벗어나도록 한다. 

* continue문

 continue문은 반복문 내에서만 사용될 수 있으며, 반복이 진행되는 도중에  continue문을 만나면 반복문의 끝으로 이동하여 다음 반복으로 넘어간다. for문의 경우 증감식으로 이동하며, while문과 do-while문의 경우 조건식으로 이동한다. 전체 반복 중에 특정조건을 만족하는 경우를 제외하고자 할 때 유용하다.