반응형

* 디자인패턴이란?

- 객체지향 하면서 여러 문제가 발생하는데, 이때 처음부터 해결하는 것이 아닌 이전에 사용했던 해결책을 다시 사용

- 객체지향 설계시 좋은 아키텍처나 설계를 재사용할 수 있도록 만든 패턴이다.

 

 GOF 디자인 패턴에서는 크게 세가지로 구분한다. 생성, 구조, 행위 패턴

 

1> 생성 패턴 

- 시스템이 어떤 클래스를 사용하는지에 대한 정보를 캡슐화한다. 

- 특정 객체가 변경되거나 추가되어도 프로그램 구조에 크게 영향을 미치지 않는다.

- 싱글톤, 빌더패턴, 추상팩토리, 팩토리메서드, 프로토타입 등이 있다.

 

2> 구조패턴

- 객체나 클래스를 조합해 더 큰 구조를 만드는 패턴

- 서로 다른 인터페이스를 지닌 2개를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴

- 퍼사드, 프록시, 브릿지, 컴퍼지트, 데커레이터

 

3> 행위패턴

- 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴

- 한 객체가 혼자 수행할 수 없는 작업을 여러개의 객체로 나눠서 분리, 그렇게하면서 결합도를 최소화

 

반응형

'개발공부 > 디자인패턴' 카테고리의 다른 글

디자인패턴1. 팩토리 메서드 패턴  (0) 2018.08.30
반응형

예외처리는 개발자의 숙명인것 같다.초반엔 이 개념에 대해 크게 고려를 안했던것 같은데 개발을 하면서 적절한 처리를 하는것이 추후, 시간을 낭비하지 않는 방법이라는 것을 알기에 토비의 스프링 중 예외처리 부분은 따로 정리한다.

 

 

예외를 처리할 때 피해야할 것들

1> 예외 블랙홀

try {
	...
} catch (Exception e) {
	
}

 

기껏하여 예외를 잡아, try~catch를 사용해놓고, catch 문에 아무런 액션을 하지않는 경우, 

이 경우에는 개발자 및 운영자가 예외가 발생하였는지를 못알아차릴 뿐만 아니라 예외가 발생하여도 아무런 대책을 취하지 못하는 최악의 방법이다.

 

try {
	...
} catch (Exception e) {
	sytem.out.println(e); 또는 e.printStackTrace();
}

이 역시, 로그에 뿌리기만 할뿐, 지나가면 못잡는 예외처리이다. 필자는 이 경우에 차라리 잡지말고, 상위클래스에 throws로 예외를 전달하여 책임을 전가하라고 한다.

 

2> 무의미한 throws

public void method1() throws Exception () {
	method2();
}

public void method2() throws Exception () {
	method3();
}
...

모든 예외를  위로 던져 버리는 throws 역시, 심각한 문제점이 있다. 무조건 복붙하여 넣었는지..아니면 이 예외를 어느선에서 잡아야 하는지 에외를 다룰 수 있는 기회를 박탈해버린다.

 

예외의 종류와 특징

1>Error

시스템에 비정상적인 상황이 발생했을 경우에 사용, 주로 JVM에서 발생시키는것이기 잡아도 대응방법이 없다. 따라서 이 에러에 대한 처리는 신경쓰지 않아도 된다.

 

2>Exception과 체크예외

Exception에서는 체크예외와 언체크예외로 나눠진다. 이 둘의 구분은 RuntimeException을 상속했느냐 아니냐의 차이다.

RuntimeException을 상속했다면, 언체크예외이다. 일반적으로 예외라면, 체크예외를 말한다. 사용할 메소드가 체크예외를 발생시킨다면 try~catch로 잡든지, throws를 사용하여 위에 던져야한다.

-> 일부에서 이에대한 비난이 있다. 강제하여 오류를 잡게하기 떄문에 불필요한 throws를 남발할 수 있기 때문이다.

 

3> RuntimeException과 언체크/런타임예외

명시적인 예외처리를 강제하지 않기 때문에 언체크예외라고 불린다. 에러와 마찬가지로 런타임예외는 catch문으로 잡거나 trhows로 던지지 않아도 된다. 오류가 있을때 발생하도록 의도된 것들이기 때문이다. nullpointException이나 illegalArgumentException 은 개발자가 주의하면 피할 수 있다. 개발자의 부주의에 의해서 발생하는 것이기 때문에 발생하도록 만든것이 런타임 예외다. 충분히 예상할 수 있는 상황에서 발생한 예외이므로 예외처리를 하지 않는다.

 

예외 처리 방법

그렇다면 이러한 예외들을 어떻게 처리하여야 할까? 다음과 같은 방법이 있다.

 

1> 예외복구

예외상황을 파악하고 문제를 해결해서 정상상태로 돌려놓는 것이다. 예외로 인해 기본작업 흐름이 불가능하다면, 다른 작업흐름으로 자연스럽게 유도해주는 것이다. 예를 들어 파일 전송이 되지 않으면 사용자에게 파일 업로드를 다시하라는 로직을 추가하거나, 네트워크 접속이 원할하지 않으면 일정 조건을 두어 해당 횟수만큼 재시도를 하도록 유도하여야 한다.

int maxTry = MAX_RETRY;

while(maxretry --> 0) {
	try {
    	..	//예외 발생 가능성이 있는 코드
    	return;
    } 
    catch(Exception e) {
    	// 로그출력, 정해진 시간만큼 대기
    }
    finally {
    	//리소스 반납, 정리작업
    }
    
    throw new RetryFailedException; // 최대 재시도 횟수를 넘기면 excception 발생
}

 

2> 예외처리 회피

자신이 직접 처리하지않고 throws로 예외를 던지는 방법이다. 또는 try~catch로 로그만 남기고 throw로 예외를 던지는 방법이 있다. 하지만 긴밀한 협력관계가 아니면 이는 다른 메소드에게 책임을 전가하는 무책임한 회피가 될 수 있음을 기억하자.

public void add()  throws Exception {

}
public voi add() throws Exception {
	try {
    	...
    } catch (Exception e){
    	//로그출력
        throw e;
    }
}

 

3> 예외 전환 

발생한 예외를 그대로 던지는게 아닌 적절한 예외로 전환하여 던진다.

 

이에 대한 목적은 두가지가 있다. 첫째, 의미를 분명하게 해줄 수 있는 예외로 바꿔준다. 예를 들어, id가 중복인 예외라면 sql익셉션보다 idDuplication예외를 선언하여 던지는것이 더 의미가 분명할 것이다.

 

둘째, 예외처리를 강제하는 체크예외를 언체크예외로 바꾸려는 경우 사용한다. 어차피 잡기 불가능한 예외라면, 런타임예외로 포장하여 던지게 하여 다른 계층이 코드를 작성할때 불필요한 throws를 작성하는것을 막아준다. 코드에서는 런타임예외로 던지고, 에외처리 서비스 등을 이용하여 관리자에게 메일로 남기거나 로그로 던지는 등의 추가 로직을 넣는것이 바람직한다. 

 

출처: 토비의 스프링3.1 vol1

반응형

'개발공부 > Spring' 카테고리의 다른 글

Spring에서 Bean을 주입하는 방식  (0) 2020.03.16
SPRING AOP  (0) 2018.07.02
SLF4J와 Logback  (1) 2018.06.26
Tiles란, Spring tiles3 적용법  (2) 2018.06.14
반응형

실수를 하여 기록해둔다.

 

Java Map 객체에서 값을 빼올 때 

 

예)

HashMap<String, Object> apiResponse = new Map<>();
logger.debug(apiResponse.get("aaa").toString());

aaa라는 이름의 객체를 빼온다고 하자. 

이때 값이 null이면 NullPointException 이 떨어진다. 이때는 값을 굳이 형변환을 할필요 없이 값 앞에다 알맞은 형을 명시해둔다. 이미 Object객체임으로 컴파일러에게 String이라고 아래와 같이 명시해주면 된다.

 

HashMap<String, Object> apiResponse = new Map<>();
logger.debug((String)apiResponse.get("aaa"));

 

아니면 NPE 방지를 위해서 String.valueOf()를 쓰는것도 한 방법이다.

String.valueOf()은 파라미터가 null이면 null인 문자열을 반환시킨다.

String lowerCoatingVal1 = String.valueOf(destItemMap.get("LOWER_VAL"));

String lowerCoatingVal2 = destItemMap.get("LOWER_VAL").toString();

 

lowerCoatingVal1 = "null"

lowerCoatingVal2 = NullPointerException 발생

 

String.valueOf()의 null 체크

String lowerCoatingVal1 = String.valueOf(destItemMap.get("LOWER_VAL"));

if("null".equals(lowerCoatingVal1)) {

    // To do Somting....

}

 

출처 : https://swjeong.tistory.com/146,https://okky.kr/article/71363

반응형

+ Recent posts