* 예외 처리 1. 예외란 - 예외 : 잘못된 코드, 부정확한 데이터, 예외적인 상황에 의하여 발생하는 오류 2. 예외 처리기 (try-catch, throws) try{ // 예외가 발생할 수 있는 코드 } catch{ // 예외 처리 } finally { // try 블록이 끝나면 무조건 실행된다 } public void writeList() throws IOException { ... } 3. 예외의 종류 1) Error - 자바 가상 기계 안에서 치명적인 오류 발생 - H/W 문제 등으로 파일을 읽을 수 없는 경우 - 컴파일러가 체크하지 않음! 2) RuntimeException - 프로그래밍 버그나 논리 오류에 기인한다 - 컴파일러가 체크하지 않음! 3) 기타 예외 - 회복할 수 있는 예외로 반..
리팩토링
1. 리팩토링 1) 분류 코드를 상태/전략 패턴으로 치환 - 이 리팩토링은 상태(전략)패턴이라는 디자인 패턴을 이용하여 리팩토링 한다. 2) 리팩토링 카탈로그 이름 분류 코드를 상태/전략 패턴으로 치환 상황 분류 코드마다 객체가 다른 동작을 함 문제 동작을 switch문으로 나누고 있지만 분류 코드가 동적으로 변하므로 분류코드를 하위 클래스로 치환은 사용 불가 해법 분류 코드를 나타내는 새로운 클래스를 작성해서 상태/전략 패턴을 사용함 결과 o 분류 코드 타입 판별이 가능해짐 o 분류 코드에 따른 클래스 동작을 다형성으로 해결 가능 x 클래스 개수가 늘어남 2. 예제 프로그램 클래스명 역할 Logger 로깅 클래스 State 상태 객체를 나타내는 추상 클래스 StateStopped STATE_STOPPE..
1. 리팩토링 1) 분류 코드를 하위 클래스로 치환 - 분류코드의 종류에 따라 다른 동작을 한다면, 하위 클래스로 치환하는 리팩토링이 좋다 - 상위 클래스에 선언한 메서드를 오버라이드해서 다형적 메서드로 만드는 것이 핵심 2) 리팩토링 카탈로그 이름 분류 코드를 하위 클래스로 치환 상황 분류 코드마다 객체가 다른 동작을 함 문제 switch 문을 써서 동작을 구분함 해법 분류 코드를 하위 클래스로 치환해서 다형적 메서드를 작성함 결과 o 동작이 클래스별로 나뉨 x 클래스 개수가 늘어남 3) 구조와 동작 - 구조 : 프로그램의 정적인 성질 - 동작 : 프로그램의 동적인 성질 👉 분류 코드를 하위 클래스로 치환 리팩토링은 하위 클래스라는 '구조'를 새로 만들거나, switch 문 하나에 모여있던 '동작'을 ..
1. 리팩토링 1) 분류 코드를 클래스로 치환 - 분류 코드는 객체 종류를 나타내는 값 - 분류 코드가 int와 같은 기본 타입이면 분류 코드 범위 밖의 값이 사용되거나 다른 분류 코드와 착각할 수있음 👉 타입 판별이 되지 않는 또는 타입 세이프가 아닌 문제 2) 리팩토링 카탈로그 이름 분류 코드를 클래스로 치환 상황 객체를 식별하기 위한 분류 코드가 int 같은 기본 타입임 문제 타입 판별이 안됨 해법 분류 코드를 나타내는 새로운 클래스 작성 결과 o 분류 코드의 타입 판별이 가능해짐 x 클래스 개수가 늘어남 2. 예제 프로그램 클래스명 역할 Item 상품(책, DVD, 소프트웨어)을 나타내는 클래스 ItemType 분류 코드를 나타내는 클래스(리팩토링으로 새로 작성) Main Item 사용법 예제 클..
1. 리팩토링 1) 클래스 추출 - 기존 클래스에서 필드와 메서드를 추출하여 새로운 클래스로 옮기는 것 2) 리팩토링 카탈로그 이름 클래스 추출(Extract Class) 상황 클래스를 작성함 문제 한 클래스가 너무 많은 책임을 지고 있음 해법 묶을 수 있는 필드와 메서드를 찾아 새로운 클래스로 추출 결과 o 클래스가 작아짐 o 클래스의 책임이 명확해짐 x 클래스의 개수가 늘어남 2. 예제 프로그램 클래스명 역할 Book 책 클래스 Author 저자 클래스(리팩토링으로 작성) Main Book 사용법 예제 클래스 1) 리팩토링 전 public class Book { private String _title; private String _isbn; private String _price; private St..
1. 리팩토링 1) 메서드 추출 - 한 메서드에 세세한 처리가 많을 때 그런 처리를 묶어서 나누고 독립된 메서드로 추출하는 것 2) 리팩토링 카탈로그 이름 메서드 추출(Extract Method) 상황 메서드를 작성함 문제 메서드 하나가 너무 김 해법 기존 메서드에서 묶을 수 있는 코드를 추출해 새로운 메서드를 작성함 결과 O 각 메서드가 짧아짐 X 메서드 개수가 늘어남 2. 예제 프로그램 클래스명 역할 Banner 테두리 안에 문자열을 출력하는 클래스 Main 동작 확인용 클래스 1) 리팩토링 전 public class Banner { private final String _content; public Banner(String content) { _content = content; } public vo..
1. 리팩토링 1) 널 객체 도입 - 널 객체를 사용하면 '이 변수는 현재 null인가' 라는 확인을 생략할 수 있음 2) 리팩토링 카탈로그 이름 널 객체 도입 (Introduce Null Object) 상황 객체를 다룸 문제 Null 확인이 너무 많은 경우 해법 Null을 나타내는 특별한 개체를 도입해 ‘아무것도 안 함’ 이라는 처리를 하자 결과 장점 : null 확인이 줄어든다. 단점 : 널 객체만큼 클래스가 늘어난다. 2. 예제 프로그램 클래스명 역할 Person 사람을 나타내는 클래스(이름과 메일 주소를 담는다) Label 표시 가능한 문자열을 나타내는 클래스 Main 동작 확인용 클래스 1) 리팩토링 전 public class Person { private final Label _name; pr..
1. 리팩토링 1) 어서션 도입 - 어서션 : 프로그램의 의도를 확실히 밝히면서 실행 시 조건이 반드시 성립함을 보장 2) 리팩토링 카탈로그 이름 어서션 도입(Introduce Assertion) 상황 코드 속에 성립해야 할 조건이 있음 문제 주석으로 ‘이런 조건이 성립한다＇라고 적어도 프로그램 실행 시 확인되지 않음 해법 어서션 넣기 결과 o 해당 부분에서 성립해야 할 조건이 명확해지고 소스 코드의 가독성이 좋아짐 o 버그를 빨리 발견 가능함 o 어서션을 활성화하면 어서션이 성립하는지 자동으로 확인 가능함 o 어서션을 비활성화하면 어서션이 무시되어 성능이 개선됨 x 어서션을 지나치게 사용하면 오히려 읽기 어려워짐 주의 • 자바 컴파일러는 어서션을 무효화해도 어서션 부분 코드를 삭제하지 않음 • 어서션 ..
1. 리팩토링 1) 제어 플래그 삭제 - 처리 흐름을 제어할 때 사용하는 플래그 : 제어 플래그 - 제어 플래그가 나쁜건 아닌데 지나치게 사용하면 처리 흐름 파악하기 어려움 2) 리팩토링 카탈로그 이름 제어 프래그 삭제 상황 처리 흐름을 제어한다. 문제 처리 흐름을 제어하는 플래그 때문에 코드가 복잡해집니다. 해법 제어 플래그를 삭제하고 break, continue, return을 사용한다. 결과 O 조건 의미와 제어 흐름이 명확해짐 X 단순 반복에도 무리하게 적용하면 코드가 부자연스러워집니다. 방법 (break, continue을 사용하는 경우) 1) 제어 플래그로 제어하는 반복문 찾기 2) 제어 플래그 할당을 break나 continue로 치환 3) 컴파일 (return을 사용하는 경우) 1) 제어 ..
