[JAVA] 객체지향(3)

Abstract Class(추상 클래스)

자식 클래스에서 반드시 부모 클래스의 메서드를 재정의 해서 사용하기 때문에 부모 클래스에서의 메서드 구현이 무의미한 상황

-> 함수에 대한 정의는 있어야 하는데 몸통은 필요 없을 경우 abstract 사용. abstract 메서드는 abstract 클래스에만 있을 수 있다.

 

부모 클래스에서 해당 메서드의 선언부만 남기고 구현부는 세미콜론(;)으로 대체

abstract 키워드를 메서드 선언부에 추가 (구현부가 없다는 의미)

abstract 키워드를 클래스 선언부에 추가 (객체를 생성할 수 없는 클래스라는 의미)

 

추상 클래스의 특징

- abstract  클래스는 상속 전용 클래스이다.

- 객체를 생성할 수는 없지만 자식 클래스를 참조할 수는 있다.

- 부모 클래스에서 상속받은 abstract 메서드는 자식 중 한명은 꼭 재정의해서 사용해야하는 일종의 빚이다.

 

Interface(인터페이스)

사용자는 기능 구현에 관심 X

개발자는 인터페이스에 따라 내부 기능 구현에만 관심 O

 

- 클래스와 유사하게 interface를 선언한다.

   public interface MyInterface{

     ... 

   }

- 모든 필드는 public static final이며 생략 가능

- 모든 메서드는 public abstract이며 생략 가능

- 전통적 인터페이스는 선언부만 작성 가능하지만 JDK 8에서 default method와 static method 가 추가되었다.

    : default method : 객체 상태일 때 호출 가능, implements한 클래스에서 재정의 가능

      static method : 클래스명, 메서드 형태로 호출 가능, 재정의 불가능

- 인터페이스는 다중 상속이 가능

- 인터페이스끼리 extends 키워드 이용하여 상속 가능

- 다형성 확장

- 모듈간 독립적 프로그래밍 가능

인터페이스를 implements 한 클래스는 모든 abstract 메서드를 Override해서 구현하거나 abstract 클래스로 표시해야 한다.

 

Exception Handling(예외 처리) 

· 예외처리 : 예외 발생 시 프로그램의 비정상 종료를 막고 정상적인 실행 상태를 유지하는 것

· Error : 일단 발생하면 복구할 수 없다.  -> 디버깅 필요

 ex) 메모리부족, stack overflow

· Exception : 수습될 수 있는 비교적 약한 상태의 오류. -> 프로그램 코드에 의해 수습될 수 있는 상황

 ex) 읽으려는 파일이 없음, 네트워크 연결이 안됨

 

· 예외 클래스 계층

 - Checked Exception : 예외에 대한 대처 코드를 필수적으로 작성하지 않는다면 컴파일 진행 불가

 - Unchecked Exception : 예외에 대한 대처 코드가 필수적이지 않지만 예외에 대한 책임은 개발자의 몫! 컴파일 단계에서 이상이 없었다면 unchecked exception

 - Checked Exception : 예외에 대한 대처 코드를 필수적으로 작성하지 않는다면 컴파일 진행 불가

 - Unchecked Exception : 예외에 대한 대처 코드가 필수적이지 않지만 예외에 대한 책임은 개발자의 몫! 컴파일 단계에서 이상이 없었다면 unchecked exception

private void printMessages(){
	int i=0;
    String[] greetings[] = {"Good bye", "Hi", "안녕!"};
    try{
    	while(i<4){
        	System.out.println(greetings[i]);
            i++;
         }
     }
     catch(Exception e){
     	System.out.println("Error :" +e);
     }
 }

· 예외처리는 try ~ catch 구문으로 처리한다.

 - 예외가 발생할 것이라 예상되는 곳을 try 블록으로 감싸기

 - 예외가 발생했을 때 실행할 코드는 catch 블록에 작성

 

try-catch문 실행과정

- try 블록에서 예외가 발생한 경우

  1) JVM이 해당 Exception 클래스의 객체 생성 후 예외 객체를 throw 

  2) 던진 예외 객체는 catch 블록의 argument를 통해 전달 받음, 전달 받은 예외 내용에 따라 적절하게 예외 처리 코드를 실행

  3) try-catch 블록을 벗어나 다음 문장부터 정상적으로 코드 실행

- try 블록에서 예외가 발생하지 않은 경우 catch 블록을 실행하지 않고 try 블록 실행 후 다음 문장부터 정상적으로 실행

※ finally 구문은 예외 발생과 관계 없이 무조건 실행

 

다중 예외 처리

try 블록에서 여러 종류의 예외가 발생한 경우 하나의 try 블록에 여러개의 catch 블록 추가

· 다중 catch 문장 작성 시 순서 유의

  - JVM이 던진 예외는 catch 문장 찾을 때 다형성 적용

  - 상위 타입의 예외가 먼저 선언된 경우 뒤에 등장하는 catch 블록은 동작하지 못함. 컴파일 에러

  - 예외 클래스 중 최상위 클래스는 Exception. 맨 마지막 catch문에 작성한다.

 

Throwable의 주요 메서드

public String getMessage()	발생한 예외에 대한 구체적 메시지 반환
public Throwable getCause()	예외의 원인이 되는 Throwable 객체 또는 null 반환
public void printStackTrace()	예외가 발생된 메서드가 호출되기까지의 메서드 호출 스택 출력. 디버깅의 수단으로 사용

Throws 키워드를 통한 처리 위임

 : 예외 처리를 발생한 곳이 아닌 메서드를 호출한 곳에서 처리하고 싶을 때 throws 키워드를 사용한다.

-Unchecked Exception 계열은 throws 키워드를 사용하지 않아도 예외가 전달되기 때문에 throws 키워드 생략 가능하지만 명시적으로 throws 키워드를 작성하면 코드 분석에 유용@

 

사용자 정의 예외

: 사용자의 필요에 의해 직접 예외 클래스를 만들 수 있다.

 - 대부분 Exception 또는 RuntimeException 클래스 상속받아 작성.

 - Checked Exeption : 코드 복잡하지만 예외 처리 누락 X

 - Unchecked Exception : 코드 간결해지지만 예외 처리 누락 가능성 O

· 장점

 - 예외 객체의 활용

 - 코드의 재사용

 - 코드의 간결성 향상

 

Collection Framework(컬렉션 프레임워크)

· Generics

: 꺼낸 객체가 뭔지 모르는 불편함을 해소. 데이터 형식에 의존하지 않고 하나의 값이 여러 데이터 타입을 가질 수 있게 한다.

 - 미리 사용할 타입을 명시해서 형 변환을 하지 않아도 되게 함.

· 클래스 또는 인터페이스 선언 시 <> 에 타입 파라미터 표시

   public class 클래스명<T>{ ...}

· 타입 파라미터 : 임의의 참조형 타입. (반드시 이렇게 할 필요는 없지만 암묵적 규칙)

 - T : reference Type

 - E : Element

 - K : Key

 - V : Value

    ※ 타입 파라미터로는 참조 타입(Reference Type)밖에 올 수 없다. int, double, char과 같은 타입 대신 Integer, Double 으로 쓴다. 

· 객체 생성 시 변수 쪽과 생성 쪽의 타입은 반드시 같아야한다. 

 - 클래스명<String> 변수 = new 클래스명<String>();

 - 클래스명<String> 변수 = new 클래스명<>(); <- 더 자주 사용

public class ClassName <T> { ... }
 
public class Main {
	public static void main(String[] args) {
		ClassName<String> a = new ClassName<String>();
	}
}

· Generic Type 객체를 참조할 때 와일드카드(물음표)를 이용한다.

Generic type<T>	타입에 제한이 없음
Generic type<? extends T>	T 또는 T를 상속받은 타입들만 사용 가능
Generic type<? super T>	T 또는 T의 조상 타입만 사용 가능

· 컬렉션 프레임워크

: 객체나 데이터들을 효율적으로 관리할 수 있는 자료구조들이 있는 라이브러리

<3대 주요 인터페이스>

 · List(일렬로 줄서기): 순서가 있고 데이터 중복을 허용

  - ArrayList

  배열을 사용하여 데이터 관리

  메서드들이 존재하여 데이터 추가/삭제가 간단하며 사용이 쉽다

  장점 : 데이터 접근 속도가 빠르다(데이터의 인덱스 번호를 알고있는 경우)

  단점 : 비 순차 데이터의 추가/삭제 속도가 느리다.

  - LinkedList

  Node 객체를 사용하여 데이터 관리

  각 노드는 다음 노드의 주소값과 데이터로 구성

  장점 : 데이터의 추가/삭제 속도 빠르다.

  단점 : 데이터 접근 속도가 느리다. (첫번째 노드부터 순차적으로 검색)

  - Vector

  ArrayList와 동일 구조 + 동기화 된 메서드로 구성되어 멀티스레드 환경에서 안전하게 객체 추가/삭제 가능

  단점 : 하나의 스레드에서 Vector 객체를 점유하는 동안 다른 스레드는 추가/삭제 불가능하여 속도가 느리다.

 

 · Set(주머니 속 구슬) : 순서가 없고 데이터 중복 불가

  - HashSet

  데이터 순서 없이 저장, 중복 불가

  - TreeSet

  데이터 오름차순 정렬 저장(이진트리로 정렬된 상태로 요소 관리), 중복 불가

    ※ Set에서 동일 데이터 기준 : equals()가 true를 return, hashCode() 값이 같으면 동일 데이터 

 

 · Map(Key, Value의 쌍으로 데이터 관리) : 순서가 없고 Key는 중복 불가, Value는 중복 허용

  - HashMap

  스레드를 고려하지 않아 Hashtable에 비해 추가/삭제 빠르다

  - TreeMap

  Key 데이터 기준 오름차순 정렬 저장(이진트리로 정렬된 상태로 요소 관리)

  - Hashtable

  동기화된 메서드로 구성되어 있어 멀티스레드 환경에서 안전하게 객체 추가/삭제 가능

  단점 : 하나의 스레드에서 Hashtable 객체를 점유하는 동안 다른 스레드는 추가/삭제 불가능하여 속도가 느리다.